I started with Mercurial at least a year before Git and found roughly as many areas where I preferred either one. Having taught a number of people how to use the basics over the years, I’m highly skeptical of claims that either is a substantial barrier compared to learning how to use a version control system and work well with other contributors.
A summary of the stuff I liked: histedit feels much more natural than rebase -i, and I rarely need to look up arguments.
When rebasing, I frequently found that I needed to look up what was what of the three refs git can take (source, dest and onto).
hg undo, unamend and split take complicated flows in git and make them trivial.
I don't think I ever got as good an understanding of the hg model as I had with git, but I had to get that understanding because I screwed up my repo and wanted to fix it. I've never done that in hg.
I have only once had a VCS lose data, but that was amusingly the opposite: mercurial, before they had a standard rebase-like mechanism, so the only takeaway I’d draw is that a feature like that needs to be very well tested.
It even worse. Git makes certain things bloody near impossible. Want to find deleted files across all branches in git? Good luck.
In Mercurial, it's "hg log --template "{rev}: {file_dels}\n"
So, the most reliable solution to finding deleted files in git is to convert the repository and then run the query in hg.
<facepalm>
git log --name-only --diff-filter=D --all --pretty="format:deleted in commit %h"