It seems pretty straight forward to me,
#1 Core access? Keep existing review process in place, could take 6 months, sorry. Patches that will never get committed for you! #2 Extension access? Has a working extension attached to submission (has some .php files in it, no need for a code review here, the community will handle that) . Granted. Create their account, and give them access to _only_ their extension directory.
If you want to foster a more communal and helping extension community, when it comes to do core access reviews, use a script to spit out active people on svn, and if any of them only have access to their extension directory, pro-actively have a short sentence or two about if you should give them access to all extensions. If yes, let them know the happy news, maybe they will do something with it (likely not, even if they had it in the first place). Another metric might be if they have a lot of tickets for other core extensions with patches attached.
They can't be that destructive in their own space, and if they have a complete working extension, chances are people in the community will start using it, and invariably come into irc complaining if the quality is low, better to nip this one in the bud and get them into the code review process early. Like all the people being so helpful to me in IRC. I don't want to wait months to find out I've been doing things all wrong.
For extension access there isn't many reasons why you can't make them an account on the spot and see how it goes, whoever is around and sees it first (even Sumana).
I haven't used git, but won't you need to decide what gets comitted in git as well, no matter what they comit on their own HD? It will still be 'get it moved into a extension branch on git, have your revisions reviewed, get it into the extension distributor'. I see this applying no matter which way you go.
Just my 2c to the pile, now banking a dollar. - Olivier