Well, that's not entirely true. To summarise my arguments from this discussion:
1. There is ample evidence of real and serious costs due to software failures. The NHS fiasco is a clear example, and hardly the only one in recent times.
2. There is ample evidence that we can build high quality software if we are willing to adopt alternative methods and tools. Many safety-critical areas already do. (Note that this point has no reference to cost.)
3. There are techniques that can self-evidently be adopted with negligible cost and still make some improvement. C, and by extension C++, are languages that have many fundamentally dangerous elements that have literally no benefit, and which are often avoided by more modern languages.
(To expand on this point with a few more examples, there is no need for null-by-default, or ubiquitous types like enumerations and void pointers that aren't type safe, or standard library functions to deal with null-terminated strings that have no mechanism to prevent buffer overruns, or allowing silent confusion of = and == in a conditional expression. These things have caused countless bugs over the years, that would be entirely avoidable in new software today.)
4. So far, we have established that serious problems are caused by poor software quality, that much better quality is achievable without reference to cost, and that some improvements can be achieved with negligible cost. What remains is the question of what the cost/benefit curve looks like between those established extremes. How far to go for any given software development project would then necessarily depend on the nature of the software and the risks associated with its failure.
5. The human cost of software failure may be extremely high in individual cases and is certainly high in aggregate, but the developers of that software are often relatively unaccountable for those failures. One way to promote improvements in quality is to increase that accountability to more realistic levels in line with other products and services. This would encourage developers to experiment with better development processes and tools rather than staying in their comfort zone, which in light of the above is not an unreasonable strategy if our goal is to reduce those human costs.