Agreed.

For example, once you have a good grasp of the codebase, and an overview of the future requirements, you can perform low-risks, local refactorings, so as to ease implementing both current and later features/bugfixes/etc.

The requirements aren't systematic though. Meaning, as a dev, you're not always, at least explicitly, allowed to get a bird-eye view, nor to act on it.

I don’t think it does - it only says badly designed is a more stable state. You can roll a boulder uphill in very small steps, as long as you can also keep it from rolling back down (analogous with other devs in your team/new requirements to implement).

I think we can look into the notion from complexity theory of attractor states. If you want to make a change, you need to shift your system enough that it moves into another state.

In more normal words - the codebase will fight your changes. And that means that small incremental changes may not be enough, and you will need at least a few big leaps.

Not impossible, no. But it it moving uphill, in the opposite direction to the path of least resistance.

Not just uphill, but also through thunder and flames.