In using a distributed version control system, I found the ability to create what you might call micro branches quite useful. In an environment where we were juggling lots of small changes to a large system, being able to create a local staging environment and repository for each small feature is extremely helpful.
The problem with putting all of that in the central repository is that, aside from Subversion's branch merging difficulty, it would clutter up the repository with branches. From the POV of the main repository, each of these minor fixes were coming through as normal commits was quite nice, even though on our desktops they amounted to micro branches.
How big of a problem is a microbranch in Subversion? Greg pointed out that they aren't stored efficiently, but if you make a modification in a branch and then integrate it into the trunk, it only doubles the storage of diffs, no more (at least if I read his comment correctly) -- that doesn't seem so bad. I know I underuse short-lived branches, but Subversion doesn't disallow them; you can delete a branch as soon as you are done with it. The only real issue is that its merging is rather poor, so it discourages branching.
That said, I do see the usefulness of "spontaneous branching" as Mark termed it. There is a certain oddity to the special place the checkout has in Subversion, where in distributed systems there isn't anything quite like a checkout, and there's an opportunity to be somewhat more cohesive as a result.# Ian Bicking