My current idea of handling technical debt is to keep track of how much resources it actually consumes and then make decisions.

Trying to rewrite everything in a new, shiny way leads nowhere. The warts and hacks of the old code may well be there for a reason, and you can't learn all the corner cases by just staring at the code. Which means that the new system will be just as buggy and just as hacked and full of suboptimal decisions because of time pressure. Been there, done that.

Trying to swallow your pride and get the job done leads nowhere. It hurts one as a professional and leads to passive aggression building up. In the worst case you only earn gastritis or angina.

Proposing changes and steering the discussion is a good thing. If that's not encouraged by management or ignored by colleagues, that's a bad sign about the workplace as a whole. But even if they do embrace the discussion, it's a long way to go and you get 80% of all proposals turned down. That's an uphill battle, and it has to be fought.

Writing comments that explain the legacy stuff and the reason it's done in this way is a good thing. As knowledge accumulates, it may become obvious how to clean things up without breaking them or starting from scratch.

Taking care to not break the work of others is a good thing. Even the best and shiniest API change shouldn't ruin the team's Friday night. Deprecate things gradually. If a better function cannot be trivially wrapped to emulate a worse function, it's not yet better in the first place.

Sometimes a rewrite has to be done. But it must be justified by evidence and sanctioned by the team and the business guys. Like, we wasted X money because of bugs and downtime and development of new system to this spec is Y money and Y < X.

That's my opinion. It's changing over time. I'm still learning.