I struggled with this. I didn't have the guts to not use "tech debt" in the title and throughout the book. I wanted to coin a new term, but didn't find anything that worked.

There are parts of the debt analogy that (I think) really hurt getting it dealt with. I think that explaining it like that to non-engineering decision makers will make them think they understand it and then quash projects based on some kind of ROI analysis of debt payments. They'll be happy to have the debt.

Debt is the right metaphor. Some amount of tech debt is virtually unavoidable; just like w/ $, a low-interest student loan or mortgage might be a great investment, while using a high-interest-rate credit card, or usurious payday loans, represent catastrophe. Cutting a few corners for the sake of GTM is often the former. Forgoing proper tests, or letting PoCs shape architecture, is more like the latter.

I don't see "swimming" replacing it anytime soon -- and the energy you'd expend trying to shift the metaphor might be better spent elsewhere.

That said, "swimming in debt" still works, as a fairly common and intuitive metaphor. Break-even is treading water, profitability is flying above the waves, and accruing debt can put you in Davy Jones' locker.