The thing is, what you're saying directly contradicts reality. You have fewer developers stepping over each other to make changes when they aren't constantly m

The thing is, what you're saying directly contradicts reality. You have fewer developers stepping over each other to make changes when they aren't constantly merging in things that have a high likelihood of changing. If someone makes a change and pushes it to master I can just as well rebase my work on top of their commit, make any changes I might need to should there be a conflict, and go on my way without having to merge anything. If I use merge in that same situation I can end up with a string of useless merge commits that contain conflict resolution practically hidden away from the real work. Logical grouping of commits is still completely possible with merging as I said, when you use --no-ff merging into the branch after having rebased on top of it. For example, if I have a branch topicA, I can, having fast-forwarded master and being on topicA, git rebase master, git checkout master, and then git merge --no-ff topicA. This will give you the only acceptable merge commit, with a history that shows where your branch diverged from master and what commits it contains.