I have been using "squash and merge" for a few months and just recently switched to "merge pull request" in GitHub. My opinion is that "merge pull request" is much better option than "squash and merge" for our case.
Brief Background
Here is a brief background to my case. The software development process (10+ developers) for this "project" is extremely chaotic and monolithic so a lot of changes are deployed "chaotically" which basically means they deploy whenever developers and/or testers think it is ready. So I may get changes A, B, C, D, E, F but may be deployed C, A, E, F, possibly never B, and D could be "maybe" on hold for a year or tomorrow.
For some reason, I am responsible for the implementation of git (with no prior experience). I am a deployment manager (technically release coordinator... whatever that means). Please forgive if I butchered the purpose of git. Also our tech team is extremely reluctant to change which means I am not going to change process over a minor issue even if it is the industry norm.
Environment
We have 3 environments: DEV, STG, and PRD.
Each has only a single instance. Master branch is what is in production.
Stage branch is what is in stage. Stage branch also almost like a fork of master but still technically a branch. By this I mean it is a branch that I never merge with feature branches or master branch. All changes are cherry-picked from the feature branch.
The feature branch is a clone of master. All pull requests are for the feature branch onto master branch.
Please accept that this is the scenario. As to why we do it this way will be too long to explain for this post.
Squash and Merge
Pro
This was pretty cool to see on the git history. A nice single line and easy to see issues with merges. As I will learn later, this is a very minor pro.
Con
Although I knew that a squash and merge created a new commit id, I didn't fully realize what implications this meant.
For a long period of time, I have been merging the changes to master so I have been doing all the conflict resolutions in git. While trying to get the developers to get into the practice of merging master into their feature branch (particularly really old changes), I found that there were a lot of differences from my personal expectations.
I had thought that git will compare the differences to the final result, but it actually compares the commit history. Because it is a new commit id, this throws a lot of flags at git.
Merge Pull Request
Pro
Merges are much simpler if developers update their feature branches with changes from master branch.
Con
"Messier" history. It's not pretty looking. But from my experience, there has been no real value to seeing a pretty history because there is nothing to get from it. With a merge history, git will know which commits to merge. Also if there is an issue, there is more information in the history. A clean history won't be very helpful.
Conclusion
"Squash and merge" is positive only cosmetically. When things are good, I don't need to look at the history. When things are not good, there is usually not enough information. "Merge pull request" is helpful in both the merge and in troubleshooting. For those who skipped the above, this is based on our process.
If we following a process that was closer to FIFO, then the Merge Pull Request would be slightly less beneficial which I then can potentially see a case for Squash and Merge. I would still prefer Merge Pull Request.
If there was maybe a case for using Squash and Merge, that scenario would be if pull requests were on the development branch (eg feature branch). I have lots of commits of minor fixes and I want to bundle them all together so there is less commits to review when troubleshooting.
