Technical Debt is different. Technical Debt slows future velocity for feature development / changing to fit customer needs. That you are "leaving money on the table" with these choices does not impede feature progress at all.
I use Slicehost, which is rather more costly than similar VPS options such as Linode. This costs me something on the order of $2,000 a year -- but it works, almost flawlessly. With sufficient time available, I could theoretically migrate to Linode (or EC2 or wherever) and shave off ~40% of that bill, but I don't have to. There will never be a day where I say "Aww effity I wanted to develop features or do marketing today but I can't because if I don't get off Slicehost right the heck now I will suffer angst-inducing downtime."
Technical debt, on the other hand, looks something like this: the printing code in the Java version of my software is an offense against God, and I cannot incorporate new features into it without a complete rewrite. No kidding -- I want to be able to put a title on those bingo cards, but it architecturally just will not support that. It is a mess of kludges and a class hierarchy descending from FailFactoryServiceLocator, held together by duct tape and prayers. The fact that it functions at all is a miracle.
That is technical debt: I would like to incorporate new features my customers want into that version of the program, but I just can't until I rip its rotten heart out and start over. That is, in fact, so much technical debt that I'm probably just going to End Of Life the sucker and concentrate on the web version and my new projects rather than deal with it.
patio11 gave a great example from his project, but I'll add one other thing.
I actually have an extra category for tickets that I file explicitly called "technical debt." Whenever I "screw my future self," as I heard someone call it once, I make sure to write it up, so that when I have some spare time, I can go back and fix it.
Most of these issues are fairly minor. "I know I have the same code here, here, and here, I should refactor it." Next time I'm touching that part of the codebase, I'll take care of it. But knowing is half the battle.
