Technical debt is a former technical asset without its owner.
To be fair, leaving aside how fitting or unfitting it is, the metaphor is too kind to cause any reaction at all.
If you say "we can take a bit of technical debt to get more work done today, we can always pay it off later", people would nod and move on. The reaction you get would be, at most, on the same level as someone watching TV news about a tragedy on a different continent ("Oh no. Anyway...").
But if you say "we can cook today's meals without washing any pots/pans/spatulas/etc and save time and money that way, we can just keep doing it every day until the first roaches appear", even though the message probably gets across way more clearly, you'd get a warning to watch your language and keep it appropriate, and how dare you compare the company to such a nasty restaurant.
"Our technical debt is starting to become too much" doesn't ring the same as "there's too many roaches and they are actually starting to get in the way of our cooking".
The metaphor was kinda improvised so I'm sure it has other bad parts. The way I thought about it was with the kitchen being the service or codebase, and the utensils being utils/functions/modules/etc. Nothing more. So I bet there's more ways this metaphor can break.
Use at your own risk.
The paper is well worth reading, but the TL;DR if you don't wanna: the "theory" of a program (how does it fit together? What extensions/modifications would work well, how should it evolve to handle new cases, etc.) is contained only in the mind of the coder; documentation, spoken explanations, etc. are attempts at describing that theory, but they are necessarily a lossy encoding of it. Certainly attrishing everyone who knows something about a codebase would be extremely foolish under Naur's argument.
Debt, I guess to me, is code deviating from a known better theory for it to follow.