The common argument is linear and cleaner commit history. In practice, I find that to be a pretty weak argument _for_ rebasing. I have worked in teams where hundreds of PRs merge a week and merge conflict isn't a rare occurrence. My personal take is: use whatever your team/organization mandates, if they don't, use whatever you are most comfortable with for your workflow.

I personally find the argument that merge commits introduce cognitive load for reviewing or cherry-picking and reviewing are, again, pretty weak. Unless somehow `main`/`master` is changing so frequently (it can) and the person working on their own branch is obsessively updating their branch against `main`/`master` with merge commits, it's never an actual problem. I suspect people who legitimately find merge commits a problem for cherry-picking and reviewing actually have other problems to deal with, such as their workflow.

Merge commits _could_ complicate the use of bisect. However, that's only really a problem if you're not testing regularly, and/or your organisation doesn't have a proper CI pipeline set up. If you have good observability tooling, good CI/CD pipeline, and disciplined development workflows, it's not often you need to use bisect — and by the time you need it, you are probably dealing with a regression that wasn't easily caught by the guardrails you have (which is possible because there are always tradeoffs you have to make for every part of the system). I love bisect, but I also don't think it's a good reason for preferring rebase over merge.

My last point is that software development is a very social activity, and you will see merge commits in most code bases that doesn't explicitly prevent the use of merge commits: simply because of personal preferences. So arguing about which one is better is mostly pointless.

I used to exclusively use rebase exactly because I like cleaner commit history. I now prefer merge especially when an update against `main`/`master` will create a conflict because everything is contained within the merge commit; not that you can't revert a rebase with reflog + reset, but if you are working with people reverting a merge commit is much easier (reflogs are local). I also don't obsess over "clean" commit history anymore — if not having a "clean" commit history bothers you, how people write their commit messages and descriptions (or not) probably bother them too, which is an entirely different problem.

Like everything else, there are probably edge cases that I haven't had the privilege to be exposed to, so take this with a grain of salt! :)