Yes. I've been on projects that I believe would have succeeded if we'd approached them differently, with less debt. One was due to magpie syndrome - influential architects who enjoyed working with bleeding edge technology and convinced management not to listen to the more conservative recommendations of the developers who would be doing the majority of the work. The software was a wreck, and morale dropped (and the original architects left the team). I think the project would have worked with a better approach, but after a change in upper management, they decided to end the project completely.
Another was a rewrite of an application that had been very popular, but was written by someone who was actively learning on his own (a talented developer who later learned to write very clean and well organized code). It was, as I like to call it, "superglued" to the server. SQL statements that could have been handled with a join were instead handled by querying all the ids, running through them in a loop, building a new query, getting results, stashing them in an array, one by one. When those queries took too long, they were run in the background or just crashed the system. Changes were all made in place, on the prod system. There was no build, no archive, no nothing (this was in the early 2000s - even back then, this was a no-no, but it wasn't quite as shockingly unusual as it is now) I was part of a team that tried to rewrite it, but halfway through the organization was frustrated with the time and expense and terminated the project.
Interestingly, I think there's almost always a psychological or political factor in play when a project is killed purely by "Technical debt". In theory, debt itself shouldn't really play much of a role in whether a project is worth pursuing, because it's all sunk cost. If a project has a positive enough ROI that it would be worth pursuing as a greenfield project, then even the worst case scenario, trash everything and start over, is a net win.
However, I think what happens is that some people never wanted to see the project happen in the first place, or people get very frustrated with the expense, or people start to suspect that the failure was inevitable and that the technical problems are just a distraction. Think Jurassic Park (which in many ways is a story of a software project failure, a theme that is much stronger in the book). At the end, during the "post mortem", some of the characters think that the problem was in the approach. That with a bigger budget, less dependency on a few people, less corner cutting due to a lowball bid from a software developer, enforced through threats to reputation and lawsuits, that with a better approach it all would have worked. On the other hand, you have the chaotician, who insists from the start that a project like this will fail inevitably.
My guess is that if it was ever worth pursuing, it is always worth pursuing. The problem is, we can never really tell. Sometimes failure due to technical debt is taken as a sign that this failure was inevitable. Other times, it isn't.