See this discussion: http://git.661346.n2.nabble.com/Re-Regulator-updates-for-3-3... on the git developer mailing list for more details on why that merging strategy is not liked.
If you do code-review on the contributions/pull requests then I can see where the merge-often strategy causes issues. The auto-generated merge commits don't give you the context of the updates that are pulled in and will lead to having to spend time going back through the commit tree. It may not lead to the introduction of issues or regressions but you can't be sure.
However, if you're set up as a small team with good internal communication or a high level of trust, then merge-often can be a good thing in that you usually aren't left with big merge issues to deal with and you're more likely to have any conflicting updates fresh in your mind.
One thing to keep in mind is that it might lead to a number of merge conflicts that may be difficult or tedious to resolve depending of how the branches have diverged. Merging may avoid these.