EDIT: Looks like my iPhone's Google Chrome has submitted several copies of this post at varying stages of completion - strangely apropos for a post about SCM. I'll try and tidy it up now...
I don't have particularly strong opinions about source control apart from Microsoft SourceSafe which, bluntly, isn't.
I had many years using Perforce which is about the most competent centralised SCM of which I'm aware - its merge tracking is significantly better than Subversion's comparatively primitive equivalent, and the fact that it tracks client state centrally makes updates fast on even large repositories. Features such as being able to "shelve" pending changes to the server is also handy, somewhat akin to Git's stashing. It was certainly a massive improvement on the CVS I'd used prior to that (and RCS before that, although that's delving back into university days).
I've heard it may have scalability issues with very large teams (thousands of users) but it's quite possible this is admin error. As an aside, their customer support is also brilliant.
However, with boring predictability I've become quite a fan of distributed SCMs lately so my current choice would be Git, although I must confess I've only used Mercurial and Bazaar very lightly when I've come across projects which use them, and I've never had occasion to try BitKeeper or darcs.
I know some people find Git confusing at first and this doesn't surprise me too much - it's been written by a bunch of Unix hackers and it shows in the raft of minor inconsistencies and quirks across the command set. However, I personally like it for the same reasons I like C and Python - it contains a core set of very competent functionality, which takes a small set of simple concepts and combines them in powerful ways. There is then a clearly separated layer of more complex functionality built on top, but you can always go back to the basic principles to understand how this is working.
I think Git definitely rewards some careful background reading in how it works under the hood - it makes the usage patterns significantly easier to understand in context. I even went as far as to write my own little reference to Git structure which helped cement my understanding.
That said, Git is still a fairly low-level tool and is more of a toolkit with which to design a process than it is a definition of the process itself. This is in contrast to more centralised systems, which tend to be designed to support particular processes or methodologies. As a result, any teams using it need to be prepared to layer their own set of policies on top - for example, deciding whether to use a truly decentralised model or have a "golden" central repostitory that everyone pushes to, whether to gate commits on reviews being performed, how release and feature branches should be used, etc. These are decisions that face any team using SCM to some extent, but Git tends to offer more options and hence requires more decisions.
I'm a sufficient fan of Git that at my current employer, who uses Subversion, I personally use git-svn to layer a local Git repository on top of the Subversion one. This works really well as long as you use the SVN repo as your one true upstream repository - if you peer with other Git repos, it can become confused.
So, if I had to recommend an SCM tool it would be Git for preference (assuming a technical audience) or Perforce if a centralised system is mandated.