That's the nicest thing I've heard anyone say about SVN ever.
Sure, why not? I create a branch for nearly every series of edits (aside from tyop-fixing bugfixes) that I do, usually to fix a bigger bug or to create a new feature. If it works out, great: I merge it into the master. If it turns out to be a dead end, or is taking too long, I can delete the branch, or just put it aside with the intention of rebasing it later.
...but I don't think branching too much is particularly healthy.
Again, why not? Ignoring for the moment problems which are social at their root and not a dvcs' fault, most likely either you're creating lots of dead ends in those branches, which isn't such a bad thing because it also means that you're also trying out lots of ideas and exploring the problem space; or you're merging those branches, so you're doing good work and getting it integrated into the project.
With a centralized VCS (or more specifically a single- or few-branched repo), you just tell people to checkout code, commit their changes, and you're done. There are less places to screw up because you don't have a bunch of branches you have to manage. You are less flexible, but this lack of flexibility only becomes a huge burden in a truly distributed (i.e. open source) environment.
It's sort of like arguing static vs. dynamic typing. There are many cases where dynamic typing resulted in very painful errors because some variable along the line didn't follow the "gentleman's agreement" that it should be a list and not a string. Though dynamic typing is more flexible and powerful, sometimes you just succumb to human error because the computer trusts you.
Does anyone here seriously work like that?
Seems like git has some advantages if you branch a lot, but I don't think branching too much is particularly healthy. I can see why it's good for open source if you have a ton of contributers, but what's the win for a small team who hardly ever branch?