@JohnShiple I do agree that frameworks are great. Writing a game from scratch when Unity is available? Coding raw JS animations with jQuery? These things are hard to imagine these days. It seems we've both seen the bad use of frameworks. I think what we're both saying, and I see throughout this thread many saying that it depends on the quality of your tech team.
In business, it is hard to quantify technical debt and in many cases hard to know why to pay top $ for engineering talent. Let's say your building an MVP. For $100k you can hire the A-team, who will complete it in 2 months with 0.9 robustness. For $50k, the B-team will complete it in 3 months at 0.9 robustness. So who do you hire?
Seems obvious to hire the B-team right? I'll wait a month to save $50k. For you, the result is identical - equivalent features, with equivalent # of bugs.
But what you don't see is what we could call the mutability index of your MVP. The A-team has delivered something that is far cleaner, better structured, with all the right engineering constructs in place to robustly modify the behavior. While the B-team's solution is patched together, or written in the wrong technology, or something like that. So, when you need to add the next set of features, the A-team suddenly gets relatively less expensive. At some point, the A-team is actually cheaper, feature-by-feature, than the B-team.
This is what I think matters - the ability for you to quickly grow, or repurpose the tech. Seems necessary if you are going to grow and compete in the fast digital world. This lack of mutability is my understanding of the term "technical debt". However, it could also be looked at as a lower asset value and - as a creative - that's how I more tend to think of it;).
This debt can be accumulated for a number of reasons - many mentioned above. It would be great if non-technical managers could chose, say Agile over Waterfall, or a certain process of documentation, Ruby on Rails or whatever to avoid it. But the truth is that, for all these decisions, I've seen cases where each choice is the best for maximizing mutability of the final result at minimal cost. So, you are kind of helpless to avoid it, and have to trust in your tech team. And choose a team with an eye towards how much that future mutability is worth to you. You can ask your A-team to cut corners to save cost, at the risk of future mutability. But in my experience, even given infinite time, weak technologists cannot develop highly mutable versions of complex systems.