Motivation
If you can't make time to tackle tech debt it will just keep on growing, and once the ball of mud is big enough, nobody can move anymore.
Applicability
Most teams have quite a good idea of how much tech debt they are accumulating in their code. But since it can be hard to convince some Product Owners of the need to work on such "purely technical" issues that do not deliver any features, and there is always one more workaround one can apply, it often accumulates.
At a certain point, there is so much tech debt that tackling it would consume a significant percentage of development resources, at which point it becomes even harder to persuade the PO to invest that much time.
Application
Be prepared for the fact that some Product Owners, especially those with little technical experience, or those under a lot of pressure from stakeholders to deliver features, find it hard to understand the need for work that doesn't appear to "deliver" anything. Try to explain why keeping tech debt within manageable levels is a task that should have a reasonably high priority.
If you are already facing a backlog of tech debt - and most projects will, because it is also not economical to do everything perfectly - don't hide that fact during estimation. Resist basing your estimates on ugly hacks or workarounds - if implementing a certain feature means that a certain item of tech debt needs to be tackled, include the tech debt work in the estimate.
Otherwise, a Product Owner will never see the strangling influence of tech debt on the team's ability to deliver features.
Consequences
With luck, you should arrive at a situation where tech debt is monitored and kept within levels that are deemed manageable within the context of your project - levels that have been agreed by the team and the PO.