There are two problems here, feeding into one another.

Firstly, many codebases are difficult to edit, so refactoring is more expensive than it ought to be. The scoped "refactorings" you describe are often veiled rewrites, because that part of the codebase has been totalled. In other engineering disciplines, this usually involves some kind of catastrophic accident - but in software engineering, because nothing physically explodes, catastrophes are routine. When engineers are forced to meet an impossibly short deadline for a complex feature, causing so much damage that it triples the cost of editing that module, don't expect an invite to a post-mortem meeting; most of the time, the mistake won't even be acknowledged.

Secondly, most engineers suffer from a low-trust working environment. All substantial work requires authorisation, and to be authorised it needs to be visible to non-technical managers. Such environments either drastically reduce maintenance work, or eliminate it completely; an unmaintained codebase will inevitably fail, like a machine that nobody is oiling.

When code is cheap to edit and engineers have more control over their own time, spontaneous drive-by refactorings become viable, and poor choices are no longer locked in. (We could daydream about going even further, and setting up an engineering team where it's safe to talk about casual maintenance work in front of your managers, so that it can be organised and systematised - but let's be realistic here...)