This is simply not true - in particular, it's untrue outside the internals of the drive itself. Checksums generated by firmware in the drive won't do the first thing to detect or correct corruption occurring anywhere at or above the drive's controller interface. Dodgy SATA port? Firmware will never know about it. Dodgy SATA cable? Firmware will never know about it. Dodgy SATA port on the other end? Firmware will never know about it. Dodgy RAM in the system? ... you get the idea.

My comments were meant about data coming from the hdd read channel, not the rest of the PC. I am confident that modern day hard drives are going to return good data or no data (sans firmware bugs or hardware failures). But with respect to those other components, what you see isn't caused by bitrot, that is caused by faulty parts. I suppose if you have dirty data sitting in memory for extended periods of time, bitrot could be an issue (I highly doubt the OP would ever run into this though), but that is where ecc memory comes into play.

My argument is that the chances of bitrot are so small for a normal user that it shouldn't be a concern. You are talking about hardware failures causing corruption, which I agree is something you should protect against.

What's your scenario that accounts for this in any other way than the drive either writing data incorrectly, or reading data incorrectly?

I admit the firmware of storage devices aren't infallible, and the cause of most failures (especially ssd's) is caused by firmware bugs. I can't tell you the reason that data corruption wasn't caught, but I'd bet its a bug and not something caused by "bitrot".

ZFS certainly isn't a bad idea, the benefits of another layer to check data integrity may be worth it if the data being stored is really that important. I think its more an issue of catching hardware/firmware failures rather than bitrot that magically slips by the many layers of checksums on the media (given the correct data was written in the first place).