There's a tradeoff between the costs of trying to detect possible issues at various stages, and the costs of damage if those issues aren't caught until later. This makes the caught-earlier-is-cheaper analogy not always hold, because the costs you spend to detect an issue at some stage can easily outweigh the costs of the issue itself at any later stage. Hence the industry doesn't follow NASA practices, or even more reasonably make use of TLA+ as basic professional practice like unit tests have largely become. Many bugs have such negligible impact that they remain unfixed, regardless of when they were caught, regardless even of whether the customer found them or knows about them. We also realize that some bugs still make it past everything and get to production, so it's worthwhile to spend effort trying to reduce the cost of production bugs, which might for instance involve having a faster and smoother deploy process.

So in hiring, there are costs companies pay to avoid a bad hire, and costs that result as a consequence of bad hires -- which they mostly can only estimate because of bad hires getting through anyway, everything on the consequences side is formally probabilistic. You can think of it as hiring-filter-costs + P(bad-hire) * consequences-of-bad-hire. So yes, if P(bad-hire) is 0 because of your amazing hiring filter, then you'll never have to pay for the consequences-of-bad-hire. And supposedly, increasing hiring-filter-costs should decrease P(bad-hire), though over time we've found many practices that don't actually do that, and smarter companies have stopped doing them.

My thinking boils down to we can and should reduce hiring-filter-costs (which I want to think of as including opportunity costs and negative externalities on the whole industry, but it's not necessary), but fear prevents even experimenting at many places because there's an idea that any reduction will increase P(bad-hire) too much, and consequences-of-bad-hire are too large. So, why not focus more on identifying and lowering the consequences-of-bad-hire? Do that, and we'll also be able to lower hiring-filter-costs even if they increase P(bad-hire), which they aren't guaranteed to do anyway.