Granularity
Part of the reason Subversion works better for me is related to point 12 in the article. It's not that I need access controls, as I'm only using Subversion for my own projects, but I do appreciate the granularity. With all my projects in one repository I can export a directory, with full history, at any level: it could be a project, some small reusable part of a project, or a directory containing multiple projects with inter-dependencies.
With Git I either have to put multiple projects in one repository, which means I can't easily distribute them separately, or I have to put each one in its own repository which entails deciding what exactly each project is, and then dealing with the relationships between them outside of version control (or using submodules or subtrees which I will discuss in a moment).
It is useful to be able to distribute projects separately: I might have a well polished low-level library which I want to distribute, and a project that uses that library that's kind of a mess. The latter might a place where I explore new things before moving them into the core library; it might also be a testing ground for library functionality.
If I develop those things in separate Git repos, then the relationship between the two projects is not (easily) recorded in version control. Yes, you have Git submodules or subtrees, but they are more complex than simply having the two (or more) projects sitting wherever you want them in Subversion. Things are more complex because you have now different kinds of directories inside your top-level repository: normal directories and sub-repos. You cannot simply move a file or directory from one place to another and commit that change as a single atomic update if it crosses repository boundaries.
If you don't want to deal with submodules or subtrees (which many people don't) then any time you want to make a change that affects multiple inter-related projects, you will have to make separate changes to each repository. This is more work and puts a burden on your configuration management because you now have to know, for all the projects, which versions can be deployed with which. With Subversion you can make this kind of change as a single commit. Then every revision of the source tree automatically represents a valid configuration of project versions.
The granularity advantage of Subversion is also seen when deleting projects. With Subversion you can freely delete a project knowing that if you ever want to go back and look at it again, it will still be there in the revision history. Having deleted it in Subversion, you don't have to see it any more. With a Git repo, you can't really delete the whole thing if you think you might ever possibly want to look at it again. You have to keep all these old dead repos hanging around forever.
Branching
It might come as a surprise to realise that Subversion actually has more flexibility than Git when it comes to branching. If you work strictly with a trunk, branches and tags top-level, you can already do everything that Git allows (minus the risk of accidentally wiping out all your branches and tags). But you can also create branches and tags at any level you want, for projects here, sub-projects there, groups of projects elsewhere. You can also make side-by-side branches if you find it helpful to have project and project-v2, checked out at the same time.
Branching is conceptually simpler in Subversion, because it's not some special operation that changes the entire contents of the repository: it is just copying. The tip of each branch is a directory somewhere, and you can think of the set of branches as growing through time, with each revision being a cross section through all the branches. Every currently living branch is present in the latest revision.
With Git, branches are modal: you can only be on one branch at any given moment and whatever that is, it makes up the entire contents of your working tree. You can only really branch the whole repository and you can't have two branches checked out at the same time without having two copies of the repository checked out.
With Subversion you can safely delete a branch (directory) that you have finished with. It will always be there in the history if you ever want to look at it again so you don't have to keep it around. By contrast, when you delete a branch or a tag in Git, you've made it difficult or impossible to ever find it again. So, just like the old repos themselves, branches will tend to hang around.
The way Git does branches means that the tree structure is simpler: commits (each representing an entire working tree) can be represented as points connected by edges.
With Subversion, any pair of directories having common ancestry represents a branch structure, so branches can be different 'sizes' (they are not all whole-repo sized). Theoretically you could have branches inside branches, and do things like partial merges. A Subversion branch structure is potentially much more complex and subtle than Git's directed acyclic graph, and I'm not familiar with any tooling that might help with discovering and visualising that structure.
