This is only an hypothesis, but hear me out.

When a developer warns a PM about a growing technical debt, they are talking to somebody who, by definition, thinks about time. But they don't make the decisions — or set up the environment that induces the decisions — that could lead to reducing that technical debt. That comes when they pass the warning to people who think in terms of finance.

And here's a thing that's intuitive for people who "think in finance" that's not intuitive for people who don't: Not having enough debt is as bad as having too much. Debt, in a finance/business context, is just another component in your system. It's true that it can be overused either by mistake or deliberately, but that applies as well to even basic programming concepts like recursion or encapsulation.

When a finance/business person hears about technical debt, they don't think darn it, we need to pay this down as soon as possible. Their intuition is we need to grow faster, so it's not the time to lower it. And at least half of them will be thinking no wonder the project is going too slow, their debt-to-equity ratio is too low!.

There's a mismatch of metaphors here: in finance (very roughly speaking) you can have as much debt as you want as long as you use that debt to get enough income to not default in that debt. The metaphor breaks down in programming because you can grow faster for a bit by ignoring present and foreseeable technical problems, but being larger doesn't bring you resources to "pay" the interest in that debt: partly because just throwing new people at a bad system doesn't make it better, but mostly because when you grow up the demand will still be to keep growing. Any new resource you get from the growth you "bought" with shoddy development will be used for more shoddy development. And because growing shoddy software requires supralinear resources, that growth will be slow, which will lead the business people to care less for technical debt, which will make the problem worse.

The company might keep growing. It might in fact be fantastic business success. But the software...

Here I go from hypothesis to speculation, but if the problem is that the metaphor we are using doesn't have the connotations we think it has, we need to use a different one. As an experiment, instead of we are accumulating technical debt, try saying we are losing scale potential (that's not very catchy, you'll figure out a better one). This has two advantages. One, it's true: shoddy software doesn't scale. Two: unlike debt, potential scalability is something finance people care very, very much about.

If you do it, let me know how it goes.