If you write code that detects stack smashing and illegal dereferences then you can terminate the webservice and either have a watchdog restart it or if it crashes multiple times have it taken out of service by the load balancer. There are plenty of ways to handle hardware errors without throwing out the hardware and getting "better" hardware. Technically, You could have a faulty component somewhere between the Ram and CPU and then what is your expensive ram going to do? What if the CPU cache has errors? For many small businesses often the difference between success and failure is their ability to make things work without throwing cash at the problem.
Even with your proposed checks there remains a high probability to just get silent application data corruption, not crashes.
Regarding faulty components, that is one part of ECC's job, but the other part is correcting the regular bit flips that happen with nominally operating DRAM.
Flagging faulty components is more useful than you propose. There are not that many places where this corruption can occur, so being able to rule out RAM is very useful. The example you used, CPU caches, is actually already covered by ECC in most CPUs, including reasonably recent x86/amd64.
The tradeoff would be more worthy of thought if ECC was much more expensive
ECC ram is not a raid. If corrosion on a trace causes a bit flip from an adjacent line then the ram will recieve rhe corrupt data as valid. There is no parity ram stick to recover from. I never said ECC ram doesnt have a purpose. Im saying you are wasting your money if you think it's essential to running a web sever. Lets be real here, like 80% of computers on the internet stream porn. They dont need ecc ram
