PC manufacturers have zero incentive to add ECC when 99.99% of consumers don't care or even know.
Networking: a mixed big. Some designs manage ECC inside the processor, others use memories with ECC for specialized functions like packet QoS. Commmodity DRAM errors are a known irritant and planned for.
Servers: I'm not quite sure of my facts here, but a DRAM manufacturer would have to persuade a commmodity manager at Dell, etc, that ECC is worth it. A commodity manager won't give a d* unless his systems guys say that it's needed.
That's what's currently done with flash, but for DRAM that's not smart from a system point of view.
A long time ago ECC was done with Hamming Codes[1]; now there are similar but more sophisticated versions. These codes share a property such that the wider the word, the fewer the additional bits required. So, e.g.
8 bits + 5 bits
16 bits + 6 bits
32 bits + 7 bits
64 bits + 8 bits
That is enough for a minimum "hamming distance" of 4 between valid words. That gets you SEC (single error correction) plus DED (double error detection). You can save 1 bit if you're willing to forego the latter.Many decades ago (but I couldn't find a reference with a quick google) Micron made a chip that had on-board ECC. IIRC it was 8+4, which meant that it would internally correct a 1 bit error, but there was a possibility it would mis-correct some 2+ bit errors (which were rare).
But that meant that Micron was putting 50% more bits onto a die over a non-ECC device. They probably did this not for system reliability but to cover up the failings of their chips at the time. Yes you could make each bit smaller, but no way would it pay off if you needed to put 50% more bits onto a die.
ECC is best done with wide words. For example, a SIMM that presents a 72-bit interface can easily be built with 9 chips, each 8-bits wide.
The system (CPU, memory controller, whatever) takes in 72 bits (or some multiple thereof) from DRAM and does ECC internally. Note that as words get wider the time to compute ECC goes up. So a system could even speculatively execute using the uncorrected data, while in parallel checking to make sure that it was OK. This requires recovery in case of error, but since errors are infrequent it could be a big win overall.
It doesn't make sense for a DDRx spec to require ECC. It's cheaper and smarter to do ECC at a system level.