My experience is in medium-sized-institutions rather than giant soft-centric firm like Facebook or Google or the single-web-app startup. I think this is where the majority of programmers still work.
Here, projects "always" last longer than you think and effects of shortcuts accumulate in an unfortunate fashion.
You can say technical here is a "good choice" when it happens to be an unavoidable choice. But when it is an avoidable choice, I see it as "always" a bad choice.
-- And my quoted "always", I mean "often and more often than it is your naive impulse to think so that it's better to say always than to just guesstimate that it might not happen in this case 'cause you'll be swayed by wishful thinking"
That is, debt should be considered in this regard the same as a loan for money. Taking out a loan to get something done quickly and with little effort has a huge benefit. So does picking a framework that you can hire a lot of folks for.
Further, and this can be subtle, if you are going to do this, then you bloody use the money/technology according to the terms of the entity lending. How many people hate maven because they decided that its way just wasn't good and wanted to tweak it? How many people, on immediately taking up a new technology, look for how they want to do it first? Before they have even understood how that technology was made to be used?
This is not to say there may not be reasons to leave or tweak a technology. But, realize for most companies it is not a viable proposition to do so. Instead, accept and leverage the disadvantages and limitations of the technological "debts" you have taken out.
Consider, many folks that are writing PHP level apps do not know how the full HTTP stack works. Expand that, most people writing web apps of any flavor have a small understanding of this.
For most of us, this is not a big deal and never becomes due. We took on some technical debt by trusting the frameworks that we have chosen to handle them for us.
However, if any of us find ourselves at the scale of Facebook, Twitter, etc, then we find that suddenly a lot of the tiny details of HTTP start to matter. To the point that solutions that minimize resources and the like suddenly matter. Heavily.
All too often, however, people use this argument in favor of "shiney new framework." Taking on struts was technical debt because you offloaded much of your core to them. I question whether many companies truly needed to ditch fully working struts implementations in favor of "new shiney," though.
And then, this metaphor can be extended in amusing ways. There was the assertion that git took on unnecessary "technical debt" by remaining in C instead of C++. Instead, it can also be seen more as they took on the cost of not having abstractions unto themselves.
So, my assertion is that for most projects, the benefit of a technical debt never outweighs the downside. Not because the project will "go away" but because it just is never really a problem.
Your gambling example is amusing to me. Few people will ever consider that healthy debt. It is one thing to have a sponsor, and another to have an addiction.