Yes - whenever I'm in a team and I hear someone who insists on a linear history, I always wonder why they have trouble with merge when lots of folks like me have no problem with it.
Finally, in one team, I more or less forced a senior engineer use merge (or rather, I was in control of the project and did not force other developers to use rebase). After a year, he admitted that he no longer really saw a benefit in rebase and switched to just using merges in his own projects. He also noticed fewer merge conflicts this way.
Rebase makes sense when you realize git doesn't have branches. Git has tags that move but no branches. That means when you merge you have no clue which branch was the mainline and which was the fork. This is a question I often ask 10 years after switching to git. Sadly git has better tooling so it is worth using despite the issues.
> That means when you merge you have no clue which branch was the mainline and which was the fork.
You mean - when looking at the history?
Incidentally, once you get used to jujutsu, you realize that the question is meaningless. A merge is simply the child of two nodes. It's a symmetric operation between the two branches. The thing that makes it "complicated" in git and traditional VCS's is the insistence in assigning a name to the resulting merge (so if you're merging into main, you want to call the new node "main"). Since jujutsu doesn't automatically carry the name forward, you see the "reality" of merge being a symmetric operation (i.e. you don't merge a branch "into" another branch - you are simply merging two branches).
That is exactly my point. I'm not merging two branches together. I'm merging two branches with very clear different meanings together. One of them is our main line, one of them is a feature branch. Everyone talks about all you should develop in main line, and I certainly encourage that. However, often that just isn't practical in a large project for various reasons. Some of them aren't even good reasons, but nonetheless that is the reality.