git user interface design is a disaster. It's no wonder it's hard to document (this is a bit orthogonal to your point...).
Git has an extremely complex data structure/state: It's a forest of DAGs (commits in distributed repos), with labels on them (branches), that have specified relationships (remotes), as well as an index and a stash per DAG. All of this on top of the working directory (and .gitignore if you want).
Of course these individual elements are mostly necessary to enable complex workflows. But simple workflows interact with all of these elements too in complex ways. This complexity is neither hidden behind a sensible set of UX abstractions, nor are they cleanly exposed to the user with a set of clean elementary operations to work on them...
Mercurial works more or less the same way, and yet I find mercurial UI much simpler.
The main difference, I think, is that mercurial has stronger opinions on how you should manage your repository and hides everything that doesn't fit its views behind extensions.
Really, I don't understand how git managed to become so popular. It is really good and I like it a lot but it really takes time getting used to. I screwed up a lot before getting competent with it, and I still screw up from time to time. It didn't happen with cvs, svn and mercurial.
It makes me think of Perl. Powerful and messy, I like if for the same reason I like git. But while Perl is on the way down, progressively replaced by cleaner, more opinionated alternatives, git is becoming a de-facto standard.
I’ve always believed that it was GitHub that allowed git to win out.
In addition to that, I suspect it was the very fact that Mercurial had more features, specifically an in built web server that allowed you to easily share your repo, led to GitHub being created with git and not mercurial.
The way I look at it, Mercurial made it extremely easy to self host a repo. So there was no need for a 3rd party centralized service to share your mercurial repo. That wasn’t the case for git, so something like GitHub was needed.
But the centralization in GitHub also allowed them to add more social features, which allowed git to spread more widely.
Git has an extremely complex data structure/state: It's a forest of DAGs (commits in distributed repos), with labels on them (branches), that have specified relationships (remotes), as well as an index and a stash per DAG. All of this on top of the working directory (and .gitignore if you want).
Of course these individual elements are mostly necessary to enable complex workflows. But simple workflows interact with all of these elements too in complex ways. This complexity is neither hidden behind a sensible set of UX abstractions, nor are they cleanly exposed to the user with a set of clean elementary operations to work on them...