I now recognize that I've experienced the "always debt over risk" scenario before; it caused a slow but sure decline in our ability to deliver and in the happiness and satisfaction of the engineers. Thanks for articulating it.
I'm not sure I would characterise all technical debt as stuff you were going to fix later, or too lazy to do right. You can write the best code against the knowledge you had of the problem, and then you learn more, or the problem changes, and you're left with something that was great for the original purpose, but the purpose has changed, and it is now "debt". My point is technical debt can build up for lots of reasons, not just because something wasn't done right the first time. Read this article recently, which has some similar thinking to what you've written: [Bad code isn’t Technical Debt, it’s an unhedged Call Option](http://www.higherorderlogic.com/2010/07/bad-code-isnt-technical-debt-its-an-unhedged-call-option/)