I was working for a company, where the engineering team was doing this kind of refactoring, test development and what not mainteinance coding with large team for about 2 years. Meanwhile not many new business features were being developed and the competition took over, and eventually everyone got fired. I think the leadership was just too lazy to actually push the development of the product, but let the engineers do this pussy work of endless refactoring was big part of the problem. Not only one of course.
That's exactly it: you need balance. Not so much focus on tech for tech's sake that the competition gets to bury you but also not so little that you end up burying yourself.
When senior leadership is non-technical, they can't tell when non-customer visible changes are useful or they just have mediocre engineering. They also can't tell when their software stack is such a mess it's beyond fixing.
That's the most important job of a CTO. Communicate the cost and implications of any development done by tech team. This could be feature required by product/sales/CEO or internally by tech team.
IMO the best way is just to spend part of your time refactoring and part of your time adding features. It basically solves all the problems. You still deliver features so your company hopefully doesn't go under. And you can reduce technical debt without having to awkwardly justify not delivering features.
In my experience in the medium term (~2-5 years) it doesn't even slow down feature delivery since high technical debt can have an absolutely catastrophic effect on development speed.
At the previous company I worked in I'd say we delivered work at about 50% of the potential rate because the infrastructure they'd developed was so janky. A big Python/YAML/Makefile mess with zero static types. CI time was over 2 hours and used hundreds of CPU-hours, even for fixing a typo.
