I've had the benefit of similar illumination where I'm employed, although without the same level of patience. The same explanation was given time and again there, too; incurred technical debt due to prudence. They were small, and thus didn't have the financial wherewithal to afford a long term outage should some of that debt sudden become subject to a margin call, and so I dug deeper. And from that the true reason came out of why things had gone off the rails so bad. The political history of the company had been one where ego and authority ruled. The technical debt would not be repaid, because it would be an admission that the incurring of such debt was not inevitable. It would be a sign that one or more wrong decisions was made. And, due to the history of authority rule, no one would dare question the decisions, assuming both that the management was approaching the situation with full information and rationality, and any one else should assume to have neither. From what I've gathered, I'm not so alone in the universe with these experiences. But when the term "political history" comes out to explain something, I'll generally start reaching for my fine tooth comb, to better understand who it matters to and why.
I'd venture that it refers to bad decisions that lead to low quality of code, the problems of which are inherited by all code built on it. And so on. With every layer you pay for your past mistakes, and you quickly spend more time working around the problems than you would have spent fixing them in the first place. (or fixing the stuff below before layering even more code on)
For example, the amount of hoops I had to jump through to be allowed to fix some old code at my last job was astounding, even though the bugs had literally caused man-years of lost work, and eventually took me about 2 weeks to sort out.
I agree with pmjordan's answer, but thought I'd add an example: Your company's product log messages of some kind into a database. The developers were lazy, and put everything in one table with the classic "key, value" SQL antipattern. Subsequently, it was discovered that values weren't enough, you sometimes needed arrays of values (or hashes of values, or ...), so a (probably crappy) serialization format was written for the values so they could be arrays.
Suppose now you were hired in to this position and you actually do a lot about databases. Now, your company gets a call one day from your biggest customer that while they've been putting up with your product getting slower and slower over time (without telling you of course), it's finally gotten to the point where "queries take over an hour and we really need them in less than 5 minutes"/"our daily reporting process now requires more than a day to complete" (which means the system clogs up with nothing but reporting processes, eventually)/"we've been sued and the court has mandated that we turn over some data by next week and we compute it'll take two months"/"the CEO just tried a query that took an hour and now he wants to cancel the contract"... or so on, you get the idea.
This critical problem comes back down to you, and you realize that the only way to fix it is to entirely restructure the databases using better practices. Conceptually, this is trivial. However, since every single part of the system is built around this data system (and of course, there's no abstraction, everything uses the key/value store directly), the combination of the amount of time it would take to write the new schema, modify every program file in source control to use this new schema, write the migration script, and potentially even the time to run the migration script for the customer (during which time they will be off-line, which could be days, and which could be anything from unacceptable to impossible), oh, and testing, don't forget testing, could in fact be longer than your company can survive with a pissed-off major customer.
And if one customer is pissy now, it means every single other customer you have is a ticking time bomb.
(Everything in this message comes from things I've seen more than once in my professional career, except the hypothetical about getting sued (thank goodness). I'm not providing details because there are thousands of companies that could fill in the above!)
Your technical debt margin just got called. You couldn't cover it. It wasn't even your technical debt, but who cares? Buh-bye!
