Here's my specific issue with that: Even in such a merge it would be possible for someone to hide a change in the merge commit, and due to the nature of git it is quite difficult to figure out with confidence whether a merge commit contains additional changes or not. I much prefer the rebase/merge no ff approach over the common "just merge whatever the fuck whenever", but due to the possibility of hidden details in merge commits, i prefer a linear history.
Who is doing the merge commit? In every project I've contributed to, that's the automatic part by the code review system. If you can't trust that, then you are screwed in any workflow.
If you're talking about merges into an outstanding pull request, then that's a non-issue because any changes will still show up in the diff against the target branch/repo.
