I've spent most of my career working on systems handling money, at jobs where we actually bought and sold things. When there are bugs in the code, we lose real, quantifiable money. Sometimes being first-to-market with a product or feature is more valuable than the cost of bugs. Sometime a buggy feature makes more money than it loses. But, it's not a given, and it's naive to say that speed is more important than correctness in all (or even most) situations.

The article was written to discuss ways of reducing bugs independent of any other need.

Furthermore, although you "can't think of a single situation in which it is ever the case", I myself actually picked one where a $4 billion machine with six lives at stake was an excellent example of when it DOES matter what the quality of the software is.

BTW why did Nasa downgrade their redundancy to 2 systems in the Shuttle? I recall reading that during the lunar missions, they had 5 computers on board, all independent implementations of the same spec.

Also, the Shuttle has always had 2 independently written systems, never five. There are five computers running software written to the same spec, but the physical redundancy wasn't the scope of the article.