In my mind, there are three major categories of contributors (and prospective contributors):
1. Those that use git on a daily basis
2. Those that use hg on a daily basis
3. Those who use neither and are more accustomed to Perforce, SVN and the like
Let's say this PEP is approved and the suggested repos are moved to Github.
For git users, life is suddenly made much easier when contributing to those projects for obvious reasons. However, they still have the same barrier of entry to contributing to CPython (I would imagine that this would be the goal for most users, but maybe I'm wrong about that). I would imagine that contributing to the ancillary repos would be great grounds to ramp up on using hg before hitting CPython with its multiple long lived branches and such. Making the switch as suggested by this PEP removes that.
For hg users, you now add a barrier of entry for contributing to the repos now living on Github.
In both cases, you've introduced the need to context switch when contributing to CPython and any of the other repos. Two tools that require quite different workflows.
Then, for the third class of users, you've now introduced the requirement of learning two different sets of tools (if they want to do anything outside of using the "Edit" button through Github's UI). Now you're looking at conflated contributor documentation or project-specific documentation. IMHO, suboptimal either way you look at it.
Personally, I don't think that there are any silver bullets to this problem. In no case is everyone going to be satisfied. In cases like that, I tend to think that no matter what the solution eventually agreed upon is, consistency is of the utmost importance. Moving a number of repos to Github breaks that consistency.