Joe McKendrick, writing for ZDNet:
As Jones put it: "If you skimp on quality before you deliver software, you end up paying heavy interest downstream after the software is released for things you could have gotten rid of earlier, had you been more careful." Cunningham adds that applications themselves have a way of taking on a life of their own -- turning into "its own little bureaucracy where you can’t actually on a daily basis create value." The result is technical debt that "has piled up and you’re paying that interest."
In my career, I've seen first-hand how technical debt can impact software projects. I've seen it cause a project to be woefully over budget, behind schedule, and ultimately disappointing to users. I've also seen it completely destroy a project (at the expense of many jobs).
However, that isn't to say that technical debt must be avoided at all costs. It isn't necessarily always possible or practical to get things correct the first time. Sometimes software needs to 'bake' a bit more, especially when blazing new trails. As well, it is naive to think that shipping is unimportant (real artists ship, right?).
In short, technical debt should be minimized where possible but understood as a reality of software projects.