People are fussy about which version control system they use, to the point of starting flamewars if the one they hold dear is knocked in any way.
But there is something entirely different about the version control system "war". Because, unlike the choice of window manager, desktop system or editor, it limits which developers will be able to co-operate in your project - at least, on the face of it. Socially speaking, you then try to choose the VCS that doesn't discourage people to contribute. And therein lies the principle resistence to any change.
Subversion certainly has the upper hand on this front these days; virtually everyone these days has a good idea about how to use Subversion. Its basic tenet is simple to understand; "Build a perfect atomic filesystem that remembers the state after every commit and you will have the perfect VCS".
Subversion's model itself also allows for files and directories to be "Copied-From" other files and revisions, which allows for branches to be "cheap", essentially only the changes in the branch need be represented in the model. This is a good feature and a key selling point.
Subversion took the central, synchronised development idea of CVS, and near perfected it as well as making it simpler to understand. Despite the complexity and rampant C programmer's disease¹ in the code base, it has been successfully integrated into many places. Subversion's WebDAV module for Apache2 allows it to be one of the few version control systems that can commit via HTTP. It also means that many of the problems of distributed application management (such as encryption and access/password management) to be deferred to the web server, which is a Good Thing. User interfaces have embraced it too, with tools like TortoiseSVN (originally TortoiseCVS) and Cervisia coming to mind.
There are other reasons that people have come to fear resistence to change when it comes to version control. Version control is frequently viewed as being difficult, arcane and perhaps fragile. Files are squirrelled away into this big opaque repository thing, and only those with the know-how can get them back. VCS experts use weird and scary sounding terms like "branch", "tag", "merge", and "revert". The 'common knowledge' is that doing these things is 'hard' and shouldn't be attempted unless you're an expert.
Sometimes, VCS experts of different systems even mean different things with these terms! For instance, in Subversion, "merge" means copying changes from one place to another, typically losing the intermediate history (though you are strongly recommended to place in the changelog the revision numbers you are merging), whereas in some VCS systems, "merging" means that two branches become one, with a new word "pulling" when you are copying changes. Editors further overload the "merge" term to be the physical act of taking two slightly different file, perhaps with a "merge base" (or even "merge bases") and combining them into a result that (hopefully) has both of the changes in them. This creates further confusion exploring the deeper topics of version control, which are not actually very hard.
Branching and Tagging didn't really fit into the filesystem model - it's just not something you do with a normal filesystem - so the authors made some vague references to not being able to see in three dimensions, before shoehorning them in-band to the filesystem, a place that many things have been shoehorned into over the years. And that's not necessarily so bad. A common convention has been established, with a (hopefully immutable) tags/ directory for snapshotting releases, and a branches/ directory for feature branches and the like. Then you have this idea of a place where all 'new' or 'current' development goes on, which is usually called something like master/ or occasionally the tongue-in-cheek path ghetto/. Different projects put these directories at different levels, but for humans this is no problem. And so long as everyone can access and commit to the repository and plays nicely, it works.
You're told that the system remembers everything, so if you screw that merge up or commit it to the wrong place, it's forever there for all who care to see (update: see what I mean?). Yet despite this, newbies to VCS in general often fear a bad command undoing all the work they just did, or learning that they somehow weren't committing properly and lost 2 weeks of work.
Subversion is especially well known in the Perl community, with high-profile projects such as pugs with a wiki-style commit policy and 12,000 commits in 18 months, and with community groups such as Catalyst publishing their work via Subversion.
Despite the title of this post, I feel there is little else I need to say to the Perl community to sing the praises of Subversion - we're already rejoicing in harmony with a Version Control System that, largely speaking, Just Works™.
And with all that investment of time, goodwill and co-operation happening under Subversion in the Perl community, any change had better come with some pretty damned good pay-offs.