The worst I've had with SVN was a broken working copy, which is usually easily fixed. With Git, problems like that occur much more frequently. In the past 6 months I likely have completely wiped my local Git repository for a particular project alone more times than I've ever had to fix a broken SVN working copy. My experience is closer to the famous XKCD comic:
Now, perhaps you could argue that I don't understand Git well enough, and I wouldn't necessarily argue against that. I think Git has a terrible and confusing UI compared against other distributed systems. (And the simplicity of SVN makes its UI good, I think.)
As for performance, again, I use SVN with small projects, so performance hasn't been an issue. To be honest, I probably save time compared against Git from not having to type as much with SVN!
And I don't branch in SVN because I don't want to, not because it's difficult or dangerous. Branching would provide no benefit in my case. If I wanted to branch, I'd switch to a distributed system. My experience talking to some Git people is that they often branch as a habit without considering what could be gained from branching.
There's just never a reason to not branch. It keeps ideas, efforts, tasks separated really nicely and has essentially no cost to doing so. It lets me have a completely different environment to try things out, wreck, and abandon things without ever touching the branches that are important. When I'm done, a simple merge brings it all in at once.
These are all completely valid reasons to branch. They also don't apply to most of my projects. And for the ones they do apply for, I use Git.
My small projects tend to be relatively simple, and often contain a lot that's not code. (Some contain almost no code at all.) For example, I've had people recommend branching to keep track of different versions of the same paper they're writing. But this immediately struck me as a waste of time. I'll be submitting only one version of the paper. Why keep multiple internal versions?
I am not convinced by the argument that I can have a branch for each person I ask to read the paper. Merging in the handwritten changes they provide me is not hard. Branching would just be extra work in this case.
It can be nice to try different organizational structures sometimes, but I've found it easier to simply have a different TeX file in that case. (Or better yet, multiple TeX files for each part, and then a set of master TeX files that organize the paper differently.)
If someone has a good argument for distributed version control in this use case, I'd be happy to hear it.
There are major projects out there still using subversion. GCC for example. They have lots of branches. As for performance... well, svn is way better than CVS.
