IMO, the scary UI/UX of git is holding back the use of version control for a lot of digital documents beyond just source code. It needn't be this complicated.
On the other hand, when explaining the git model to sysadmins and developers, not sugar-coating it has worked best for me. I explain the bag-of-commits+nametable design. I explain the workspace and staging area. I show how one does things. This works for me.
Maybe git's UI "needn't be this complicated", but I do find that Mercurial's heavy-duty branches lead to hell very quickly and it's always difficult to recover -- and Mercurial is supposed to be simple! The lesson is that simplifying isn't easy, and not every simplification works well generally.
With git I can simplify in that I show users a small amount of abstract concepts (bag-of-commits, nametable) and a small set of common usages and then let them learn by experience and osmosis as they reach out for help when they stray past those usages. I can't do this with other VCSes. At some point it just becomes painful.
One of the nice things about git is that I can push users to make very linear history. This is nice because diving into the history of a tangled mess of merged branches is not easy, and it's actually very confusing to non-professionals. But even for professionals, linear history is far superior to a tangled mess of merged branches, and only git really gives us that power today.
I want a VCS that does NOT try to hide how it works from me.
I love that git gives me a) a bag of commits forming one or more rooted trees, b) symbolic names for commits/branches that resolve to individual commits in that bag.
That's such a simple model.
Remotes. Commits. Branches/tags. That's it.
Merging and rebasing merely create new anonymous branches in the bag of commits, then move a branch name (if applicable) to point to the new HEAD. Done. Trivial.
The reflog is just a local log of actions taken, and can be used to quickly recover from missteps: just find a HEAD you want as your branch's head, and then git branch -f branch <commit>.
The index/staging area are very, very useful, mostly because of git add -e, which is extremely powerful. This lets me split up my commits usefully.
Just about everything else is stuff you can figure out as you go.
The only thing you can ever lose in git (short of doing rm -rf .git) is workspace content that you have not added to the index or committed. Stay away from git reset unless you know what you're doing with it, and all is good.
Being able to think of the state of the repo as a tree of anonymous commits, with a name resolution table for resolving branches/tags to commits, makes doing complex tasks trivial for me. I often rebase in detached head mode and nothing goes wrong; when I'm done I manually move/create a branch to the new HEAD -- I can do this because the tree-of-anon-commits model is so darned simple.