Good article, you have explained the concept of Tech Debt quite well.

But I will have to disagree with the "fixed budget" approach for sure, and to an extent to the "case by case decisions" too. A fixed budget, I have seen, encourages developers to do stuff that's really not required or is not worth the effort. A typical developer does not like to maintain code written by someone else. They will claim it is spaghetti code and spend weeks trying to refactor it.

I wholeheartedly agree with "explicitly tracking tech debt in the backlog". In my opinion, a Tech Debt item in the backlog is just the same as any other item in the backlog. It has to be analyzed for impact, estimated for effort and prioritized just like any other item. PMs have to learn to ask for and quantify the impact and the benefit. For example, if the module or area of refactor being proposed has very little happening as per the road map, the impact is low.

I would like to see PMs actually understand these items and their impact. And then, they should prioritize these items just like any other feature. And while prioritizing, they should use an objective method such as RICE framework or any other framework that looks at cost vs benefit and optimizes for it. To emphasize, I would prefer that the responsibility of prioritizing Tech Debt items rests with the PMs only. This way, the chances of cleaning up code for the sake of cleaning it up are minimized.