This doesn't match my experience and it is almost exactly opposite of my personal preference of rebased commits. I get that you want to be incendiary but I think this misses the point, perhaps on purpose.
My good faith addition here: a major influence in this debate seems to me to be how a team views their repo. Merge heavy stuff makes great sense for a repo whose job is just to hold everything; essentially a big and powerful shared clipboard that has all the myriad work-in-progress. Almost like a "dumb" tool (and trust me when I say dumb with lots of love and respect - it isn't criticism it is about which direction coupling points). On the other hand, the rebase heavy approach makes more sense if you view the repo as a contextual knowledge store, holding an almost idealized version of the point in time, uncluttered by the reality of the path actually taken. To broadly generalize my experience, I've found the merge version is generally faster, has low overhead in the moment, and scales pretty well since it is nearly the lowest common denominator approach. Conversely, I've found the rebase version makes debugging and context switching faster and enables a leaner team to cover more ground because the repo has some context and documentation built in via its organization.
Of course, doing either approach poorly will have negative consequences and being inconsistent in either approach is worse than consistently doing one or the other.
I'm not trying to make an argument for which to choose but I am pushing back hard on rebase only being used by teams who are unprofessional and don't care about wasting their time.