Senior staff in pretty much all organisations are given some latitude with respect to performing tasks that they believe will be beneficial without needing to produce a specified cost-benefit.

We have one-on-one catch-ups with staff, we have all-hands meetings, we visit clients, read books and articles, attend industry functions, issue press releases, meet with potential investors, etc.

There's value in all those things, but very rarely do we need to account for the fact that we spend time on them.

Senior engineering staff need that same freedom - it should be totally appropriate for them to make that call that "I'm accountable for the technical quality of this code, and I've decided that this needs to be done".

That requires some sense of business acumen - there needs to be an appropriate balance of technical investment to business investment - but that's part of the role of being a senior dev / tech lead / architect / whatever-your-organisation-calls-them.

Of course something should be gained, but that doesn't mean you can always tell how much would be or was.

There is no mature "actuarial science" of software development. The market can provide concrete pricing for new feature development; engineers can't tell you how many dollars of tech debt you're in or give three significant digits on the probability of a major outage tomorrow.

That doesn't make money/risk/time costs which are difficult to measure any less real and it doesn't make them smaller than the ones which are easy KPIs.

Nor can you necessarily look at the movement of measurable KPIs and say "man, that rewrite was a waste of money." Who's to say things wouldn't have been worse without it?

> it's almost always possible to reason and quantify and weigh the cost versus the benefits

I don't think so. As a pretty good analogy, can you quantify the benefit of replacing knob-and-tube wiring in an old house? Now consider that the house across the street keeps its old wiring for the next twenty years without anything bad happening.