My colleagues and I always use pull requests and merge them.
The PR process allows us to do code reviews in a non-threatening way. A few years ago when we used live, in-person code reviews, some developers were too sensitive to take constructive criticism of their code. (And some were too afraid to give criticism.)
Before my group began using GitHub for almost everything, we used Review Board for our reviews, which was very good. It made reviews very non-confrontational. I didn’t have a problem with in-person reviews, but I found online reviews with RB to make the process a lot smoother. I still miss some of RB’s features that GH code reviews don’t support. We continued to use RB for a little while after we began using GH, because GH’s review UI wasn’t as good then as it is today.
Getting back to merge vs. rebase: GH’s PR features now have a “squash and merge” option. A PR containing multiple commits can be squashed down to a single commit just before it’s merged. I think that would address the problem mentioned by @suvinseptue.
Besides the code review feature, honestly, I think using PRs and merging them is a little easier process for people to understand, especially if they’re new to git. It also goes along with the methodology we’ve adapted to our work. (Only work from a personal fork, not the original (“upstream”) repo. Each issue being addressed is implemented in a dedicated branch of our forks. Pull requests of completed work are made from our fork branches back to the upstream repo.)