[...] When references to commits (in emails etc.) get invalidated,
it adds confusion and extra work. Seeing this happen is what led me to
wonder why people even prefer this strategy.
I think there is a misunderstanding here: You never ever force-push rebased commits to a public repo, this would indeed change commit hashes and annoy all your collaborators like hell. In a rebase-only workflow you rebase locally, pushing your then fast-forward-only merge to the public repo. You can even disable force-pushed on the receiving side, an that's what is normally done (well, not on GitHub...).
[...] One final thing I like about merges is conflict resolution. Resolving
conflicts via rebase is something I get wrong 40% of the time. It's
hard. Even resolving a conflict during a merge is hard, but it's
easier.
Hmmm, I don't see a difference with conflict resolution in both cases, the work involved is equivalent.
Plus, the eventual merge commit keeps a record of the
resolution! (I only learned this recently, since `git log` doesn't
show it by default.) Keeping a public record of how a conflict was
resolved seems like a huge benefit. [...]
To me it is quite the opposite: In a collaborative environment, I don't care even the tiniest bit about how somebody resolved the conflicts of his branch: This is a technical artifact about when the branch was made and when it is merged.