I agree that ideally we should set our baseline much higher. It's why I promote low-defect methodologies, code reviews, static analysis, and languages (eg Ada, Haskell) that prevent/catch most problems early. The few empirical studies done on such things show it actually saves money with occasional productivity boost for one reason: huge reduction of debug time.
And the satisfied customer effect can't be ignored. ;)
Hence calling it an extreme case.
> Hacks happen by the millions with headaches being the main result along with lost time and money.
...which is a good reason to make software correct.
However, I'm not arguing about the ROI and efficiency of attaining absolute correctness; my point is that software should be correct. Ideally.
We're happy to settle for somewhere on the low side of correctness, but I don't think that is necessarily healthy or good for the industry.