I've gotten emails from people that said, in effect, "Thanks! I feel like part of the team, that you trust me with the code. Before, I was just going to fix that one bug, now, I'm excited to poke around the codebase and see how I can help."
Really, this is a variant of a theme that we see around here all the time: autonomy, mastery, and purpose. The upside is that you empower people to take mastery over the code they use, you provide them with the autonomy a commit bit has to offer, and you give them a sense of purpose: you're now helping everyone else out, too.
The primary bottom line for a larger or more established project is maintaining code quality, stability, predictability of behavior...all while still moving forward with new features. When you endeavor to achieve those goals in every commit, giving any PR-sender the keys to the castle doesn't seem like such a great idea.
As I mentioned elsewhere (and to you in discussions about open commit policies), I also don't feel like there's a good reason when Github makes it so easy to fork projects. We've worked with some folks for years off forks. I'm also not thrilled with the idea that you're going to get good developers if your developers only "really" started contributing once they got a commit bit. Just because someone's excited to drive a race car doesn't mean they're qualified.
I feel like there's got to be a middle ground between the current "fork in obscurity" model and the OP's "commit bits for everyone" model. But I'm not smart enough to think of what that might entail.
Most notably, you can backdate a commit and github won't even show it in the commit log (because it uses strict commit date order).
Seconded. This is one of the pain-points I wish github would address. The constantly broken "network graph" and complete lack of (meaningful) tools to compare forks or branches is a royal pain in the ass.
Many of the missing operations ("In which branches does commit X exist", "Show delta between A,B") shouldn't even be hard to implement.
I don't understand why github spends their resources on useless gimmicks ("streaks", "pop repos") rather than pushing their core product.
So should you really do this for all pull requests? Probably not. While I've given a large amount of users access to various projects of mine, I'm still looking for:
- Github profile: Does this user stand to lose a reputation by doing something stupid?
... which in turn was "taken from Audrey Tang's commit policy on Pugs". 
(The graph is important -- Often when I find a useful but less-than-maintained project, I search the graph to find a fork that is better maintained.)
Isn't this enough?
For really popular forks you can often see that in the members tab many sub forks have forked off them. This is a good hint for a project that has left the original repository behind.
The video doesn't go into enough detail IMHO but the TL;DW is they are making it easier to commit and putting automated processes into place to mange it(Like extensive and easy testing). Rather than a commit is hard philosophy.
I think the first 5-10 mins of the video is the important bits.
On the JRuby project, we carefully examine all incoming pull requests. At least half of them would break something unintended, and half of the remaining non-breaking PRs aren't done properly, don't match our style, would perform badly...and so on. Giving out commit access to people based on one PR and a bit of background information is not sufficient.
The problem here is one of expertise. Very few people in the world have what we need on the JRuby project. You need to be fairly meticulous about what you commit, running tests, understanding the codebase. Ideally you need to understand what's involved in building a language runtime. Just because you're a good contributor to other projects doesn't mean you're going to be a good contributor to JRuby, and we won't give out commit access to unproven devs.
Ultimately, the reasons people give for handing out commit access are almost completely trumped by Github's ability to fork repositories. You can basically fork, do multiple PRs and changes over time, and never really require commit access to be a good contributor. And we will potentially add you as a contributor if your results are solid over time (or steadily improve to where we're comfortable adding you).
My last statement on this is that I don't think I want people on the project that aren't willing to put together a good PR or patch until they're given commit access. The kinds of folks I want contributing are the ones willing to submit multiple fixes over time, willing to learn our codebase and standards before joining the team, and who have a vested interest in seeing JRuby remain solid and improve steadily.
In another situation, it is also generally good practice to let employees know you think highly of their work. Most people will try to live up to this expectation even though it might not necessary be true.