I don't disagree, which is why my original post talked about pricing technical debt
retrospectively. You don't know when the bear will charge tomorrow, but past bear charges can be highly instructive if you learn from them.
My prod ETL process is an unloved mess, and we've had enough maulings occur to learn from it:
* I learned the problem – data models drift in the production app and changes aren't reflected / properly tested in the ETL or the analytics environment. And we don't have enough monitoring in place to catch the problem when it happens in the wild.
* I learned the cost of inaction – my analytics environment is responsible for $10mm of CARR, and I know the impact to customers when it goes down. Heck, I know how much customer credit has been given out due to SLA breaches, so there's a quantifiable price today.
* I learned the price to fix it - we've estimated the effort and run cost of the new solution.
Now I've got something that I can work with: customer acquisition says they've got $4m in the near-term pipeline? OK, great, but if we onboard them with a broken system we risk spending $+x in customer credits and risk damaging our reputation. And since it costs $y to fix it, and $x > $y, let's fix it.
I have plenty of other unloved systems that are in bear country but haven't mauled me (yet), but even then you can start thinking about risks. One system is small but critical for multiple products, so my exposure is "hey every single customer is getting service credits" – expensive enough to force the monitoring/refactoring work that it always needed. One of them serves logins for ~7k users but only for one customer so my financial exposure is bounded. We don't worry about bear spray when walking around there ;)