I’m a fan of Distributed Version Control Systems (DVCSs). I think the first DVCS was Teamware. After using Teamware effectively for many years, I ran across a bunch of people who thought that Subversion was the greatest thing since sliced bread. I’ve written about this before. I think it’s just because they don’t know any better; they never used a DVCS, so they don’t know what they’re missing when they use Subversion.
I use Mercurial, but I also hear a lot of good things about git though I don’t use it. Even though Mercurial and git are rivals in some sense, I think of Mercurial and git as allies in the struggle against centralized VCSs.
I recently read an article DVCS adoption is soaring among open source projects. I was amused when it referred to Subversion and CVS as “legacy” systems. Heh heh heh.
Synchronous Messages 
I think there are organizations and work styles where a central server-based approach works better. For those circumstances, it would be interesting to see a server-based configuration built on top of one of the popular DVCSes as a backend. You could re-use almost all the DVCS tools, and the server-based approach would be considered just an additional feature of the system. Something to think about.
I agree that there are likely to be organizations that prefer a centralized model, but my feeling is that such organizations are more concerned with control than with effectiveness. With a distributed/decentralized system, I can easily imagine “control freak” types worrying about the code evolving “somewhere else,” possibly being forked, or changes being developed that might or might not make it back into the integration repository. On the flip side, it means that subsets of developers can’t easily use powerful DVCS features to exchange experimental changes off to the side. Instead, they’d have to trade patches or whatever.