Now consider technical debt. When you go to your architect and say, "I want you to hack something so that we can get it out the door a month earlier", your architect should respond with, "What are you going to do with that time I give you?" If the answer is, "I just think we need to get to market as soon as possible", then you are doing the technical debt equivalent of spending borrowed money on pizza parties.
As a reasonable architect, I need assurances that I'm going to be paid interest on the loan. If I give you a month, I'm going to need a month and a half back. You need to explain to me how you are going to make that kind of time. If you can not, then the business plan needs rethinking. No respectable banker would say, "Oh, there is a 0.1% chance of success if I lend them the money, but a 0% chance of success if I don't. I'd better lend them the money!" He says, "Come back when you have a better business plan".
The other annoying issue is that complexity in software can grow exponentially. So the cost of repaying the debt can quickly outstrip your ability to pay. Imagine borrowing money and having an interest rate of 1% for the first month, doubling every month. Seems like a wonderful idea to borrow the money, but you better pay it back fast.
The problem with technical debt is not that you must avoid it at all cost, it's that you must think very hard about whether or not you can afford it. If you can't, you should avoid it. If that puts your company out of business, then you need a better business plan.