I'm trying to polish a better 'DVCS elevator pitch'. Here are my top X reasons to move to DVCS:

1. Cheap commits are simply fun. Seriously! When you can commit with reckless abandon unconcerned without screwing up anyone else's work it's a great way to punctuate the start, middle or end of any coding session. When your commits are local you simply WILL make more of them. Having those additional commits, the history and comments that come with them are like having a whole new tool in your toolbox - a really useful new tool. 
2. That richer commit history which is always available  can literally save your ass. Pardon my French. Just in the last two weeks I was working furiously on a piece of software I was going to demo to an audience of couple hundred people. If I wasn't such an amateur I'd have put in place a feature freeze. But of course I completely busted it minutes before the demo. Thank the software gods (Linus?) I had tagged a commit earlier in the day that had the basics working.  I 'stashed' my current work and checked out that functioning version. Did I mention the network was down?  Subversion would have been a double FAIL here - needing a network AND even if I'd gone to the relatively significant pain of setting up Subversion/CVS/Perforce/VSS repo I would not have made as many commits. Git saved me from own foolishness….again.
3. One tool to rule them all and in the darkness bind them. Your customer or employer still use Subversion or Perforce or X? No problem. Git has crazy good Subversion integration so you can basically treat that Subversion repository as a slightly dumbed down remote Git repo, but locally work as you would otherwise (just know you need to rebase rather than merge branches - Google it if you care). I can't speak to Perforce integration but know it's also very popular. 
4. The cool kids are doing it. I say this not from the perspective of 'trying to be cool' (again an area of significant 'development opportunity' for me). Rather the cool kids are moving to DVCS because of how it improves their work / lives / state of mind.  Has anyone who uses and understands Git/Mercurial switched back to Subversion/CVS by choice? Nope.  That would be like throwing out your new 52 inch HD LCD TV  and opting back for a 12 inch black and white TV. 
5.  Completely set up a repository in ~9.1 seconds (that's the typing).  Why do I say nine seconds? Its because I just timed myself and how long it takes me to type:   git init; git add *; git commit -m "first commit"; That is all it takes and you are fully ready to go with working repo of the most powerful and feature rich version control system in existence. If you spend five years only working on one giant project you might not care about this point. But if you're like many(most?) developers and have lots of both small and big projects you'll appreciate this.
6. Your repository doesn't go grow legs and march away without you knowing. I've set up a lot projects in Subversion and so have you. I'd say over the last ten years I no longer have ready access to 90% of those projects. This is because hosting providers move servers and I didn't follow up. Or I'm cheap and stop paying a hosted Subversion provider. Or a company I worked with moved/restructured their repo. Or my network drive hosting my repo got lost in a move, etc. OR I'm currently commuting in a plain/train/automobile. Sure I still have the local and most recent snapshot of those code bases but that's it, no history and my current snapshot might not even compile. A Subversion repo is almost never local (because that kind of defeats a lot of the purpose). With DVCS of course you've got a full repo.   It's hard for me to say how great it is now when a customer calls me up and says "Hey remember that thing you did for me a couple years ago? I need an update to it." and at long last I don't get an instant headache wondering where that Subversion repo went I used to use with it.
7. Imagine a world where "branching" and "merging" weren't dirty words. Then step into that world. There are a lot of reasons why branching and merging with Git and Mercurial work REALLY REALLY well to the point of being almost magical. That could be the subject of several chapters, but the simple reason is branching and merging work well because they have to.  DVCS is only viable because branching and merging work really well. Someone familiar with DVCS won't blink at creating a branch to add three lines of code and then merging it back in. Its just that easy and fast.  Extract from Linus's talk: 

   The only thing that matters is how fast can you merge.
   In git, you can merge... I merge 22,000 files several times a day, and I get unhappy if a merge takes more than 5 seconds, and all of those 5 seconds is just downloading all the diffs, well not the diffs but its the deltas between two trees, the merge itself takes less than half a second.
   And I do not have to think about it.

8. With Git especially you can do some empowering, wonderful, amazing and yes even frightening things, but you CAN do them. I remember a customer calling about four years ago "I accidently checked in a master password with my source file to the public repository. Please delete it." It was a BIG public subversion repo. This shouldn't be a big deal right?  ROFL!!!  Can you say "pour a minimum of 8 hours of your best admin's time down the drain, schedule downtime and then really get that drink you need"?  With Git if you know the right commands to rewrite history you're talking a few minutes. If you don't know them then add a few more minutes to Google. 
9. There is always more to learn. OK this can be seen from two angles obviously both bad and good. Even after years of teaching Git the author of the best selling book on the tool is admittedly still learning things about Git's central commands I think it's safe to say that there is a lot to learn about Git. That being said you can certainly get by with reasonably small subset of commands to satisfy your workflow. With something as powerful and as flexible as Git there is always something new to learn. I believe this to be a good thing strange though that may be. 
10. Lightning speed. Every operation in Git is incredibly fast and objectively it is the fastest system for almost every operation. Sure a pull or push to a remote repo can be constrained by the network but it's a challenge to find any local operation that takes more than a fraction of a microsecond. 
11. Tags are NOT RIDICULOUS subver *cough* sion. OK I think this one is just a personal pet peeve but I've always been really annoyed at the way Subversion tells you create tags. Completely copy an entire directory structure? Insanity! Never mind that a tag should be essentially immutable not just a directory of mutable files.  Honestly in Subversion I never saw the reason not to just add to a comment "tag: version 2.1.5" and then grep back for that in the log as needed. Fast, recoverable, not weird and not wasting tons of disk space. Whatever the case, DVCS does it right and creating a tag probably takes literally less than one billionth the amount of time as Subversion. Subversion branches are just as bad, but conceptually at least less ridiculous. 
12. Bisect FTW! Track down where that broken thing(s) got added that broke stuff. Do so quickly and relatively painlessly with bisect. Many devs choose Git/Mercurial just for this feature. 

Bonus reasons:

The sheer genius of your fix/contribution to that open source project will enshrine your name in the hall of immortal coding giants. But first you must lay prostrate and say "Oh key master of the open source project I implore you to consider my humble contribution. I offer my patch and pray thee won't sit on it for a year."  Or at least that WAS the old way. Now you just fork the project, make your fix and click on pull request.  This is more along the lines of "Hey there, dig your stuff. I made it better. You'll want to merge in my awesomeness and it's only a click away. Or don't and people can pull from me - whatever." I literally lack the words to describe how insanely cool this is. Here is a video.

??