Many proponents of distributed version control systems (DVCSs) say the biggest advantage is that anybody can create a branch and begin working on a project. Whereas, for a centralized system (such as Subversion), the would-be contributor needs to have commit access before they can contribute.
Let's walk through this.
Obviously, this contributor can grab a tarball, make their change, and send a patch file to the project's mailing list. No commit access is required to do that. Why a DVCS, then? Well... the DVCS simplifies the retrieval and application of the patch (by the project's developers, or third-party users of the project). The contributor also gets use a version control system while developing the patch, which I'll just axiomatically state as a Good Thing.
Okay. So if they don't have commit access, then a DVCS is very handy. What would the scenario be if they did have commit access? The contributor could develop their change on "trunk" or on a branch. We've already stated this is a would-be contributor -- not one of the regular developers who already has commit access. It really doesn't make sense for this person to modify trunk directly, so let's just say the work is being done on a branch.
So why would this potential contributor not have commit access? Really? All their work is happening on a branch. It isn't like they're going to mess up the project from over there. They're going to generate some commit emails, sure, but maybe the other developers could then provide pointers, assistance, and feedback earlier than if the contributor had arrived with a patch, as a fait d'accompli. This is source control, people. Anything changed can always be reversed. No permanent harm is possible.
So why do potential contributors not receive commit access to a branch, as soon as they ask for it? For social reasons. It certainly isn't technical. Projects have an us versus them attitude, and they don't get to commit to our repository.
For reference, I'll note that the Apache Software Foundation provides branches to Google Summer of Code students. These students arrive with no credentials, they get a branch, and then work on their code over the summer. When they are done, the work can be merged back to trunk, if it is acceptable. It has worked out very well for all involved.
In the Subversion project, we set up branches for developers to try out their ideas. We say these developers have "limited commit access" rather than "full commit". I'll also note that there are no technical limitations on their commit access. Those developers could commit to trunk if they tried. But social restrictions prevent them from doing so. We've never had a problem with rogue developers, since it is so easy to undo any mistakes or intentional harm, and to remove their access.
In this respect, DVCSs are simply a workaround to social barriers put into place by projects. They do not address the core problem: projects should be inclusive rather than exclusive.