Yep, I don't disagree with you about that. To me, the cost of having to stick with a workflow that prevents it (which you describe) is still worth it to have a clean history without merge commits, but I totally understand that this is a matter of personal preference, and having a consistent workflow for everyone working on a project together matters more. Right now, I'm working on a team that uses merge commits for the first time in a while, and it's definitely taking a bit of time to get used to again, but I'm still committing to it (pun intended!)
Like if I have branch X and branch Y, and X is 1 commit ahead of Y, but I alter the comment of a commit in Y, now X is one or more commits behind Y and will not recognize identical code-changes as identical.
It gets worse if you squash a commit, where you start getting conflicts during merges and rebases even though the code-changes are the same.
I understand why these problems happen, and the ways to prevent it (don't rebase anything pushed), but it still underscores the fact that git doesn't properly accommodate its own love of rewriting history.
If git had a proper synced graph of history-rewriting actions (commit A was rewritten into commit B) then it would be able to provide better responses when doing a merge or reflist across rewritten branches.