I think the main reason why managers don't devote resources to fixing smaller tech-debt issues is that they can't correctly measure the value of such fixes or reason about them.
As an extreme example, the task of "Update the SSL certificate" is a low priority item that doesn't deliver any value, right up until about an hour before the certificate expires, at which point it suddenly becomes the highest priority task that everyone needs to drop all their other tasks for.
A slightly more realistic example would be the task of automating the certificate update process, or writing tests for that process, both of which might fail a short-sighted manager's heuristic of asking "Are there more important tasks right now?".
(Then, when something inevitably goes wrong due to the lack of automation or lack of testing, the manager blames whoever was supposed to be responsible for manually updating it, or blames the person who wrote the automation code but wasn't given the time to test it, while telling their own boss "There was nothing I could have done to prevent this!").
So, to align everyone's incentives, and make the problem less abstract, I propose the "jelly bean method". What this involves is having a jar of jelly beans, and whenever a manager tells you to ignore some technical debt to work on a "ticket" item instead, you should say "Sure thing, boss. That'll cost you 2 jelly beans". Then you take your jelly beans, and go work on the ticket, ignoring the tech-debt. However, when the next ticket estimation session happens, you bring with you the jar of jelly beans, and you weigh how full the jar now is, and use that as an inverse scale factor for all your estimates. For example, if the jar is half full, then you double all your estimates, and if it's a third full, then triple them.
Of course this isn't a scientifically rigorous methodology, and it won't make the estimates more accurate, but it should have the effect of making the manager and the team more aware of the long-term costs they are adding to the development process, which should make people less hasty to add tech-debt without accounting for it in some way. The system even allows for giving developers days or sprints where they can pay off the tech-debt: you just have to buy more jelly beans to fill up the jar a little. And even if the system doesn't have the desired effect and the level of tech-debt spirals out of control, at least you get to eat a few delicious jelly beans to take your mind off it.
Also, absence of problems isn’t a metric that leads to recognition from leadership (unless you’re inheriting a problem with the explicit mandate of fixing it). How do you attribute cause to the absence of problems? Would they have never existed anyways (in which case the opportunity cost was a bad decision)? Or do they not exist because of your efforts? It’s unfortunate, but the system doesn’t incentivize problem avoidance; only problem solving.
As an extreme example, the task of "Update the SSL certificate" is a low priority item that doesn't deliver any value, right up until about an hour before the certificate expires, at which point it suddenly becomes the highest priority task that everyone needs to drop all their other tasks for.
A slightly more realistic example would be the task of automating the certificate update process, or writing tests for that process, both of which might fail a short-sighted manager's heuristic of asking "Are there more important tasks right now?".
(Then, when something inevitably goes wrong due to the lack of automation or lack of testing, the manager blames whoever was supposed to be responsible for manually updating it, or blames the person who wrote the automation code but wasn't given the time to test it, while telling their own boss "There was nothing I could have done to prevent this!").
So, to align everyone's incentives, and make the problem less abstract, I propose the "jelly bean method". What this involves is having a jar of jelly beans, and whenever a manager tells you to ignore some technical debt to work on a "ticket" item instead, you should say "Sure thing, boss. That'll cost you 2 jelly beans". Then you take your jelly beans, and go work on the ticket, ignoring the tech-debt. However, when the next ticket estimation session happens, you bring with you the jar of jelly beans, and you weigh how full the jar now is, and use that as an inverse scale factor for all your estimates. For example, if the jar is half full, then you double all your estimates, and if it's a third full, then triple them.
Of course this isn't a scientifically rigorous methodology, and it won't make the estimates more accurate, but it should have the effect of making the manager and the team more aware of the long-term costs they are adding to the development process, which should make people less hasty to add tech-debt without accounting for it in some way. The system even allows for giving developers days or sprints where they can pay off the tech-debt: you just have to buy more jelly beans to fill up the jar a little. And even if the system doesn't have the desired effect and the level of tech-debt spirals out of control, at least you get to eat a few delicious jelly beans to take your mind off it.