Also, my experience, as non-representative as it is, has shown that cheap branching with efficient merging results in much less of a mess than everybody playing in the same sandbox and inevitably kicking everybody else's sand castles.
That just points to poor collaboration management etc though. If people don't work together properly, you're just delaying problems until people merge anyway.
The fact that DVCS allows for less rigid management alo explains why DVCS became popular so quickly in open source, I think (where the kind of collaboration managements you suggest does not scale very well).
Or you do your development in a way that doesn't break the build, and do it in several steps.
For example, just build new code that can be specified to be used at runtime, then when it works just like the existing default code, switch it over (Effectively doing your own branch).
Just as you believe that a proper social structure and sufficiently clear conventions can overcome deficiencies in software, I believe the oposite - the capabilities and limitations of software can enforce certain patterns of behavior. And in my experience DVCSs end up having more of a positive effect on the development process.