The problem is you often get in cases where the developer cannot back their intuition that something is actually harmful with facts. When it's not just pure bikeshedding about code they don't like and falsely claim to be a ticking timebomb, they fail to weigh the risks of leaving slightly offputting code in the codebase against the risks associated with significant code changes in general, which, even with tests, will still inevitably break.

Developers of all sorts tend to vastly overestimate how dangerous a piece of code may be.

To be clear, while I've seen it with other developers, I'm still guilty of this myself to this day. I'm not saying I'm any better than anybody.

It's just that I've seen how disruptive refactoring can be, and, while it is often necessary, I thought it would be important to mention that I think it should be done with care.

If you can convince a manager with rational arguments in terms of product quality, it can be a good way to make the case for a refactor, because your manager probably won't be impressed by arguments about unimportant nuances we developers obsess about.