I have tried and used Mercurial, SVN, RCS, CVS, Bitkeeper, TFS, Bazaar, Perforce, Darcs and of course Git.
Granted, Git may not be great, but it is still my first choice.
Hg is a very similar model to git but doesn't have the cli problems it does.
Darcs is distributed with a different (and interesting) model that doesn't have the cli problems get does.
But honestly for lots of teams dvcs is not that big an advantage (how many teams are syncing around github right now) which means something like Accurev might be a better choice. It uses a concept of streams which is pretty interesting and is GUI oriented which some people like.
Hg has a lot of problems. It has bookmarks AND branches (for some reason). To edit your commit history you need to pray to the elder gods and sacrifice a newborn. I consider myself pretty smart and yet my mind went completely blank every time I read about anything related to Mercurial Queues. The default install lacks too many features, you need to enable extensions to do even the most basic stuff, like stashing.
Darcs is obviously better than git, but very few people know it exists. And none of free web repositories support it.
My original comment was really hyperbolic as a response to the comment above, I don't actually think being pro-git is a sign of intellectual weakness.
That said, my main issue is that git is a good set of primitives for file change management. But its main design principles are not about SCM. It sacrifices ease of workflow for source control, in favor of making centralized maintainer worflows simpler. This is a perfectly fine trade off for a system largely optimized for a few linux kernel maintainers, dealing with lots of distributed and unorganized contributors (frequently over email).
Those same workflows are not necessarily the best way to organize a small (tens of developers) team with a linear history product.
Some time try to onboard a new-grad developer to a team like the former. You spend way more time explaining git internals and data structures than you do source control management. This just isn't true if you do the same thing with other source control systems. Its easier to explain TFS, SVN, hg, perforce or accurev (the systems I have actual working experience with) in every instance.
My opinion is, if bitbucket and github had switched business models early on (ie hg repos for free if they were public and git repos free for private repos) hg would have become the defacto standard. Its just much easier to work with for most development workflows.
Darcs is not obviously better than git, and I say that as a person that's used Darcs for many, many years (and who has at least patch in the Darcs codebase).
Darcs main feature is the simplicity of its data model. Just a pile of patches that compose to produce some code. Push and pull them at will. It's very neat.
Darcs used to have the advantage a nice interactive UI, but git pretty much stole it wholesale with all the '-p' options (git add -p, git checkout -p, git reset -p) so it doesn't win there any more.
Darcs also has the massive downside of not being able to hold more than one branch at a time in a directory. Do you want to switch contexts? 'darcs get' to a new directory and start over. On my most active darcs project I have about 50 directories all with random unpushed WIP patches in them. In git that would just be a bunch of stashes, which are much easier to search through.
I have tried and used Mercurial, SVN, RCS, CVS, Bitkeeper, TFS, Bazaar, Perforce, Darcs and of course Git. Granted, Git may not be great, but it is still my first choice.