"As an aside, I don't see why the exchange of patches in email is even relevant in a usable and complete system -- emailing files around is a crappy interface for everyone. Making it less crappy is missing the point; email is not a good file transfer protocol. But because Linus does everything in email... sigh."
Well that's a shame, because emailing patches solves 1, 2, 3, and 4. 1) It gets it out into the community. Anyone can look at a mailing list and see the patches that have been made to a project. A project I'm working on currently uses gitweb, which lists all the recent commits to a repository, with the tags and commit message visible, and you can view any patch you want with a click. 2) We attach patches to bug reports and e-mails. All our commit messages that are related to a bug report have the bug number and link back to the bug report from gitweb. Similarly, each resolved bug has a git commit id. Each author has his own repository remotely (on a server) as well as on their own machines. Anyone can find work in no time by just looking up a bug, looking at gitweb, or reading the mailing list. 3) Seriously, what could be easier to understand than a patch? Sending it in an e-mail doesn't mean someone is going to commit the patch straight out of an e-mail. Sending it in an e-mail is a good way for people on a mailing list (e.g. developers and contributors) to verify correctness of a patch and to possibly locate more flaws. 4) The whole patch concept couldn't be easier. You write some code, you commit it and the patch is generated for you, you don't even need to look at a patch at all if you don't want to. Then you can push it to a remote repository. What's more is that outside contributors can e-mail a patch or attach it to a bug report that any developer can include in their program. The project I contribute to has dozens of contributors and they often work in this way, speeding up development. They even get their name on the commit.
"But I think this can be taken further. There's nothing wrong with the centralized model. There is something wrong with the way we are using Subversion (and CVS before it). The wrongness isn't that you need a server, or a network connection, or disk space. It's that you need commit privileges."
You make no mention about how this is different for the distributed model.
Your issue with 1) is a non-issue with proper design. Centralized or not, no code is useful to anyone until you push it. Distributed systems can have one repository if you prefer, though this basically defeats the purpose of a distributed system.
Your article could say instead that not all these features are _inherent_ in distributed systems. Distributed systems (git/cogito, atleast) are a bit more low-level than CVS and SVN, which means that you have to take some sort of care when setting one up for a project. But if you're not completely braindead, this should be easy. Set up a central repository for your project, then set up repositories for each author. Make sure all authors file bugs or feature requests that they can link their commits to. And, of course, keep commits small (meaning solve one problem at a time).
As for your closing paragraph, this is plain nonsense. The point of distribution _is_ the communal aspect. With distribution, you allow (and encourage!) anyone in the community to participate in the development process. This tracks back to e-mail, which is a very convenient way for John Doe to send in a patch for a bug he found in your program. It's a lot better than having to whine to the program devs about a bug and have them solve the problem. And it's better than creating an account for John Doe to commit his one patch to your centralized repository. The focus isn't on isolation, it's on distribution; you're confusing these terms. Yes, they are related terms, but the isolation here is of a specific problem, not an entire project. There is no more encouragement to fork than with any other SCM. Anyone can grab the source for a project and fork it no matter what SCM is used. The encouragement is for different authors to work on problems in a _distributed_ manner towards the goals of the whole project.
Please, take a look at the kernel.org git trees. Read their mailing list. And try to back up your claims using their example.