it's way easier to revert the merge commit than potentially every commit that was included in it.
having everything squashed into one commit can be annoying if the commit is too large, because it can be hard to identify why a specific change was made via git blame.
With a merge commit, I can make individual commits for logical changes, potentially rebasing, or squashing commits together. that also gives an opportunity to write more intentional and informative commit messages. once i have a good changeset, I can publish a single PR for review.
I've only really taken to this approach lately, for a long time I just didn't care. As the years go by, I care more and more about what git blame can tell me. I've been maintaining some projects for a long time, and I've had to pick up many projects that don't have their original authors available for consultation. In both cases, having a quality git commit log is just a time saver.
I don't care about preserving the history from when the code was initially typed, I care about the context the log can provide me about the change sets that have been applied. I've been debating starting to include it in my code reviews: "this commit log needs more details: can you edit the commit message and do a git push --force?"
If you're dealing with a more junior team, or people that don't care about the log, it's really a toss up for me. Roll your dice on maybe an informative message helping you, or sift through 15 commits saying "poke", or squash an enormous commit and get a single sentence about it.