In my observation, the problem comes when there is a "merge main to the feature branch before merging" This step is when newbies get confused because the diffs

In my observation, the problem comes when there is a "merge main to the feature branch before merging" This step is when newbies get confused because the diffs are the wrong way, and I've seen people often losing merge hunks from master when there are conflicts which can be disastrous (not a git issue, I've seen people do the same in SVN). The proper solution IMO would be for git to have a "merge --reintegrate" which would do the opposite merge: take the main branch and merge the current feature branch to it... after success, you have a new feature branch. This is why I also prefer rebase and cleaner history (but a common mistake here is to squash after PR approval... that should be done before, not after).