This a really bad take and fundamentally misunderstands rebasing.

First off, developers should never be committing to the same branch. Each developer maintains their own branch. Work that needs to be tested together before merging to master belongs on a dedicated integration branch that each developer merges their respective features branches into. This is pretty standard stuff.

You don’t use rebasing on shared branches, and no one arguing for rebasing is suggesting you do that. The only exception might be perhaps a dedicated release manager preparing a release or a merge of a long-running shared branch. But that is the kind of thing that’s communicated and coordinated.

Rebasing is for a single developer working on a feature branch to produce a clean history of their own changes. Rebasing in this fashion doesn’t touch any commits other than the author’s. The purpose is to craft a high quality history that walks a reader through a proposed sequence of logical, coherent changes.

Contrary to your claim, a clean history is incredibly valuable. There’s many tools in git that benefit significantly from clean, well-organizes commits. git bisect, git cherry-pick… Pretty much any command that wants to pluck commits from history for some reason. Or even stuff like git log -L or git blame are far more useful when the commit referenced is not some giant amalgamation of changes from all over the place.

When working on a feature branch, if you’re merging upstream into your branch, you’re littering your history with pointless, noisy commits and making your MR harder to review, in addition to making your project’s history harder to understand and navigate.