I don't think "technical debt" in and of itself is a fatally flawed term. The issue is that any term that becomes widely used jargon loses the preciseness of it

I don't think "technical debt" in and of itself is a fatally flawed term. The issue is that any term that becomes widely used jargon loses the preciseness of its meaning. Unless you address the root problem of having terms lose their meaning, replacing "technical debt" with "maintenance load" will eventually fall into the same trap. The same can be said for "stand ups" in which most people sit down, and for "agile" which usually doesn't involve the practices that produce agility on a team. For me I like the term "technical debt" because it succinctly describes a complexity cost that accrues interest over time. It doesn't simply mean "bad code". You can work with that cost to prioritize more important work however eventually if you don't pay it down, it will catch up with you and you will be spending your time and money on paying off the interest rather than investing in your features. Another term I like to use in tandem with "technical debt" is "technical investment". Technical investment is spending time and effort on things that will return a benefit over time, either reducing technical debt, or enabling more features.