The debt there is knowing that "we will spend $500k more doing it this way (interest) but we will benefit in the meantime".
There are other factors too that make the true cost of the debt higher. For instance less flexibility as requirements change. I often find myself saying "this would be an easy change if we had initially built it in the more extensible way, but at the time you didn't need/want for extensibility so now your easy feature is actually a large refactor"
There are plenty of situation, outside software, where doing something simple now results in something more complex later. Nobody calls that debt. MBAs don't call that debt.
What you describe there is actually an ideal conversation, and when presented with that choice, managers can make the right choice for them. What you are describing is scoping, done right.
Instead what happens is they say "Well, build what you can for $1m", and you say "Ok, we can make 'a bridge' for that", and then either (a) your infantry can cross, but the tanks have to get diverted 20 miles out of the way, or (b) the tanks end up in the river along with the bridge. Since (b) is bad, you then have to spend a lot of time planning the routes for the tanks, and making sure the tanks have the right air cover, etc etc, i.e. doing more work. More likely, however, is that the manager, who is not a structural engineer, sees a perfectly good bridge and orders the tanks across anyway, causing the loss of the bridge, the tanks, and the war.
It's not debt. It's just (at best) an incomplete solution or (at worst) a bad solution that fails at the worst possible moment - e.g. database collapses during registration for the largest event of the year.
Ah, but surely, if you build the lightweight solution for $1m, and acknowledge the increased costs of managing the problems that it doesn't solve, then thats fine? Sure, but that's not technical debt either! That is scoping: we (engineers + business) identify a workable solution that provides some business value. And then we do that well. When Cunningham, for example, talks about what to do about debt, e.g. YAGNI, these are all good ideas: scoping. But the term "debt" is incorrect in this case. The term "debt" will only ever get a team in trouble as it indicates that the team is unwilling to confront the actual problem as engineering, but only as a broken metaphor.