First of all, apologies if this seems a somewhat simplistic question.
According to this answer, TCP packets are corrupted all the time without the checksum catching it.
If this happens so often, why is it not more noticeable? Shouldn't this result in corrupted images, script files containing the wrong ascii characters, etc.?
Of course people tend to run an md5 checksum on critical files, but for average and daily networking applications, why doesn't this cause more havoc than it seems to? (it seems as though it doesn't even happen, but the statistics and logic checks out in that answer)
Best Answer
It doesn't and the answer you refer to does not claim that it does. "Often" would mean that a large number of packets are corrupted relative to the absolute number of packets transferred. But this is not the case. While the answer you refer to claims that many packets are corrupted the corruption is still rare compared to the absolute number of packages transferred.
Apart from that there might be additional protections on top of TCP. For example TLS (as used in HTTPS) will notice practically every data corruption since the HMAC used for detecting data manipulation is far more robust (but has also more overhead) than the simple CRC used in TCP. While detecting problems at this stage will not cause a retransmit of the data as would be done with TCP checksum errors the connection would simply be considered broken and would thus be indistinguishable from the many others errors one gets with broken connection on the daily basis. Similar, due to the way image formats work corrupted data in an image will usually be either practically invisible or will result in the whole image being broken (failed to render or cut off in the middle), which also looks similar to typical connectivity problems.