What makes you think the hypothetical rewrite on a new technology is going to have any less technical debt?

By the time you get to feature parity with the old shitty system, your new system is also going to be shitty. In my experience, technical debt comes from three places.

1. The people who built the system didn't know how to do things right the first time.

Solution: Employ experienced people when you're building the system, the first time. If you didn't do that right the first time around, have experienced people rewrite the bad parts.

Non-solution: Rewrite the whole thing in a new technology that nobody is experienced with. (On average, your new team isn't any more skilled than the team that built the original system.) Waste time rewriting the parts that aren't bad.

2. The problem is actually incredibly complicated, and has no clean solution.

Solution: Don't do anything.

Non-solution: Rewrite the system, re-discovering all the reasons for why it was built the way it was.

3. Most of the system is actually fine, there's just a few bad parts.

Solution: Refactor the bad parts.

Non-solution: Rewrite the whole thing, even the parts that are maintainable.

--

I have seen a lot of painful rewrites, but I've never actually seen any featurefull software project that did not have a lot of technical debt.

Technical debt is always a problem. But generally I prefer refactoring existing code rather then rewriting to address technical debt, because I think the old system is well understood, and the deficiencies are known. When you blow it away, you are also creating more technical debt, but you just haven't discovered it yet.

This isn't to say "never rewrite". I am saying we rewrite way too much now.