Maybe, though as a hard and fast rule I strongly disagree.
Delaying merge increases risk. It can also make the diff impossible to review. Overhead can be increased by way of merge conflict and re-doubling of efforts that would not be necessary had the update been merged.
Other times, sometimes you want the one step to be launched so you can ensure there is no regression. Sometimes the next steps are going to take a long time and themselves are multi-pronged and would be merged in multiple parallel phases.
Sometimes you just want to get rid of the inappropriate abstraction so that someone can complete task X where inappopriate abstraction was hindering that. In other times, "worse" is in the eye of the beholder, WET'ing the code first can sometimes be the right thing to do, even if it is never re-DRY'ied.
One more example, the phrase "consistently bad is better than inconsistently good"
Sometimes you have 10 modules that all need the same update to be better. Updating just one module, while that module might be a lot better - breaks consistency and makes the codebase harder to understand overall. It is worse, even though that one module is better. Though, updating all 10 modules at the same time might be just impractical and super risky. It can make sense to do that in phases and do just one at a time. Sometimes the effort for the one module will take a few weeks. Holding all that up for most of a year does not make a lot of sense.
At the same time, trying to do it all across the whole code-base all at once, at some point that is no longer even refactoring:
"Refactoring isn't a special task that would show up in a project plan. Done well, it's a regular part of programming activity. When I need to add a new feature to a codebase, I look at the existing code and consider whether it's structured in such a way to make the new change straightforward. If it isn't, then I refactor the existing code to make this new addition easy. By refactoring first in this way, I usually find it's faster than if I hadn't carried out the refactoring first." (https://refactoring.com/)
Of note, sometimes that initial refactoring should land as its own change first. Though, that is a philosophical disagreement that is okay to have. Some reviewers want you to fix up existing problems in code you touched, and they want that in the same diff as the bug fix and/or feature update. Other reviewers want those updates to be completely separate and done one-by-one.
At my work we often do a lot of “pre-commits” for projects that require any significant amount of work. A pre-commit is usually pure moving/repackaging of code or small re-writes to how we do things now to make the PR (or PRs) for the actual feature the most straightforward and pure business-logic-only changes that we can. So, I usually tell people we rarely refactor, but maybe we do kinda what you’re recommending here.
