Of course, if you understand the underlying data model, they seem far less arcane, but that's the problem with Git that Mercurial doesn't have - you really need to understand what's happening under the hood to get proficient at it, whereas Mercurial has a far saner interface that hides the internals under a better abstraction.
* hg log by default doesn't tell them anything about the current code they're working on; it's just a dump of everything. To get the history of the current working copy they need to pass -f which they are learning in other contexts means "do something unsafe".
* hg gives commits sequence ids that can locally be used in place of the commit sha, but must never be shared across repositories.
In practice at Mozilla I have seen people run into both these issues, causing much unnecessary confusion.
I just know on my team or 5 much less technical people, the concept of version control and how to do operations in Mercury was near impossible and it fell on one person to manage merging files with master.
Also, this was a distance learning course where the head institution (MIT Media Lab) was keeping a central repo of every location's additions, and the changes made the repo so big that we had hard caps on how much data we could upload.
Later on, it fell on me to introduce git to some colleagues. Just walking them through 'checkout','branch','merge','push','pull' got them on their feet and contributing to a repo. If they hit a wall, I could help detangle the knot, but at least we were in it together.