...and often the amount more isn't catastrophically more, so they don't even think about it. The company might be bleeding from paper cuts, it might be terribly unhealthy because of it, but still not unhealthy enough to kill it.
People do get a pass on this -- you can't rigorously examine every decision and counter-factual or you'd never make forward progress. And I don't really have any great ideas on how to bridge this gap. It'd be nice if there were better ways to measure this but there aren't, so it really comes down to who is more convincing, which is often orthogonal to facts and correctness.
In my experience, yeah, but how they do it is... not what you'd expect.
Leadership has no clue about the scope of tech debt in their products and if they do decide to fix it, it will be by coming up with a bunch of ridiculously optimistic estimates and then foisting them off onto engineers who are already overworked trying to keep up with tech debt to launch new stuff. This feels awful and generally doesn't lead to anything being properly fixed because it turns fixing tech debt into a "just get it barely good enough and mark it as done."
After the inevitable surge in attrition, more often than not the tech debt is "solved" by throwing out the old codebase and starting from scratch with a new team. This is expensive, but in a lot of cases produces a better product.