I used Mercurial before Git and found it way more intuitive. I don't have much to say about the documentation, I didn't have a problem with it, but that's not the reason.

It is not just because the CLI is more intuitive, though it plays a big part.

The main reason is that mercurial is more opinionated. On a default setup, only a few commands are available, and none of them let you change the history. If you want more, you have to add an extension. These are built-in, that's just a line in a configuration file, so that's not much of an obstacle, but you have to be deliberate. It gives a natural progression, and it better defines the project organization.

With git, you have everything and the kitchen sink, literally, as it uses the "plumbing" and "porcelain" metaphor. All flavors of merge, rebase and fast forward are available, there is a git-reset command that does a dozen of different things, there is stash, the staging area, etc... The first month or two on git, I was a bit overwhelmed, none of that with Mercurial, and I already had the experience of Mercurial when I switched to git, so I was familiar with the concept of push/pull and DAGs.

Now, I tend to prefer git, though after many years, I still have trouble wrapping my head around the command line sometimes. But that's for the same reason it was so hard to me to get into it. It gives out a lot of freedom and possibilities. For example, I like the fact it is really decentralized, for example in one project the customer had a completely separate central repository we couldn't access, and they couldn't access ours, for security reasons. We worked by exchanging bundle files. At some point we also took advantage of the fact that it is possible to have more than one root commit. Also, almost all mistakes are fixable and it is hard to really lose anything (including secrets, so beware!).

For a video game analogy, Mercurial introduces you to new game mechanics as you progress, while Git makes you start in the middle of the map with all the skills unlocked.