What makes software release cycle shorter with DVCS, compared to CVCS?
I agree with Bart that the primary reason is the branching model used, but the type of version control system directly affects which branching models are viable. So we have two sub-questions. What branching model the distributed systems support better and why it makes release cycle faster?
The fundamental difference between centralized and distributed version control is, that without central authority you can't enforce linear timeline. So to make distributed version control possible, these systems necessarily had to define history as directed acyclic graph, where each revision simply has unique identifier, one or more parent revisions and may have arbitrary many child revisions that you might not even be aware of, because you didn't synchronize with the system where they were created yet.
It turns out that this approach lends itself very well to branching. You don't have to do anything to get a branch, you simply always have one. So you can dive straight to work head first and leave deciding when and where to merge it or even where to keep it and under which name until you know whether it's actually going the way you need.
In contrast all centralized systems maintain history as set of branches with linear sequence of revisions. So you have to decide in advance whether you'll need a branch, give it a name and explicitly created it. This is quite pain in the butt when you don't yet know what the idea is worth and you often simply don't know that before you start programming. Complicated by the fact that in most centralized systems the branch names are global, significant, often persistent and not easily changed, while in all the major distributed systems they are just local monikers that can be changed at whim and recycled freely. And by the fact, that all the branching and merging operations are usually quite a bit slower in CVCS.
Thus DVCS makes branches easier and therefore teams using DVCS branches all the time while teams using CVCS will be avoiding them most of the time.
Now why using branches allows more frequent releases? Well, every team will underestimate a task now and then, often when hard to track bug appears. Teams using centralized systems usually do all debugging, and most development, on trunk, because branches are inconvenient. So they can't release until they flushed out most bugs and they have to interleave development and debugging phases.
In contrast in distributed systems where all work is done on branches these can be merged together for test, tested, bugs fixed and only the work that passes tests merged separately to trunk. Resulting in trunk that has very few bugs and thus can be released more often, usually whenever an important feature lands.
It also helps that whenever there is a change in priorities, the work in progress can be trivially shelved with the branching approach used with distributed systems. In most real projects, changes in priorities happen all the time.