In Mercurial common use cases are easy, more esoteric ones are possible, and the interface is a delight. Error messages are typically lucid. Command line help is useful, as are man pages and online tutorials. Mercurial is well-designed tool with a coherent user experience. (For the record, I have also used git extensively. Mercurial is much like git, but with fewer surprises and inscrutable messages.)
The worst part of mercurial actually has nothing to do with mercurial per se: mercurial lacks an ecosystem of well-integrated services. The best option is bitbucket.org, but in many respects that pales in comparison to github. This leads to an unfortunate dilemma: The coder's experience is much better with mercurial than git, but the github community and ecosystem of tools are vastly superior to those of bitbucket.
It is possible use github with mercurial via the hg-git plugin. This works well, including with bookmarks/branches and merges, and I use this strategy for github-hosted repos.
Upshot: In my opinion, the superior SCM tool is mercurial, but the better overall practical choice for many organizations may be git.
The choice of SCM -- mercurial, git, or others -- should be made in the context of an overall strategy for continuous integration, continuous deployment, packaging, documentation, and in-house experience. For many organizations, it's likely that those needs are better met with github than with any other hosting platform for any SCM tool (as of late 2015). Largely because of github's success, more coders use git and candidate employees are more likely to have experience with it. These points recommend in favor of git. Adventurous geeks can have their cake and eat it too by using mercurial with the hg-git plugin.
Bitbucket with native mercurial repos is a close second. This is a particularly good choice for users who want free private repos (which are not available on github). I have used for bitbucket and mercurial for years, including with bitbucket issue tracking and external integrations for CI testing and documentation.
I have used git extensively, but I stay with mercurial for two reasons: I prefer its pragmatic interface and I can't live without tortoise hg, a first-rate source code GUI that enables a visualization of the code graph, pairwise diffs, and more. (There's nothing comparable for git on linux.) Despite that, I seriously consider moving code to github and using hg-git to avail myself of the more robust ecosystem.
Finally, if you're still considering git, check out http://www.xkcd.com/1597/ and http://git-man-page-generator.lokaltog.net/. They wouldn't be funny if they weren't so true.
I use mercurial for source code management, in 3 organizations on bitbucket (with native mercurial repos) and 2 organizations on github (via the hg-git plugin for mercurial).