May not be a "catastrophe", but this is a perfectly valid point.
RAM bitflips is one of the sources of bitrot. You may use ZFS, do scrubbing and what not, yet still end up with a corrupted data, because it'd be damaged before it hits the storage.
Such a blanket statement is simply not true, sorry, even if ZFS fans like to repeat such mantras. That's like saying that a server without redundant power supplies isn't a server.
Google famously ran all of Google search on a million or so cheap desktop-class home-built white boxes (for want of a better term) without dreaming of ECC.
It really depends on the workload and what your goals are. There are plenty of places to introduce bitrot aside from RAM, and it's obvious that ECC can't catch all bitrot.
If you're not checksumming/hashing, then you won't catch it either, and if you are, then the likelihood of the bitrot matching that hash is basically nil and you'll always detect the bitrot.
This makes me think: is there some sort of kernel plugin that ECC-ifies existing memory in software? Similar to how you can implement RAID in software.
I even vaguely remember a kernel module (?) that transparently performed in-RAM compression so that you effectively used less memory at the cost of increased CPU usage. Can't find it anymore though.
