I think the comparison of "Mercurial vs. Git" with "vim vs. emacs" is actually quite apt in this case. Both version control systems are better at different things - Git has more opportunities to do advanced things out of the box, and Mercurial has better portability and ease of use - and they both are designed with different principles in mind - Git with the Perlish "There is more than one way to do it," and Mercurial with the Pythonic "There should be one - and preferably only one - obvious way to do it."
And as with vim and emacs, you have people on both sides who vehemently claim that their tool is objectively better, when really it's a case of the two tools having different design goals and strengths in different areas.
The difference between "Mercurial vs. Git" and "vim vs. emacs" is that a person's choice of editor is largely independent of other people's choice in editors, and ideally your choice in VCS would be similar. But with a version control system you have network effects - if you want to contribute to a project using Git, you use Git, and vice versa. And because a few high-profile projects like Linux and Rails went with Git, Git had the stronger network effects, and ended up with a far greater share of users.
I could easily imagine everything going the other way if Linus or DHH had picked Mercurial instead of Git. So Git users need to stop assuming that the reason Git is so popular is because it's a better tool than Mercurial - it lets you do more things, yes, but that doesn't necessarily translate to "better." (Neither is Mercurial "better" than Git - it's more portable and the UI is smoother, but that also doesn't necessarily translate to "better.")
I think there is much truth in what you say. It would be interesting to imagine what may have happened had Rails not gone with Git (and had GitHub not been so slick). I can't speak for anyone else, but for _me_ personally Git being more "powerful" was most definitely a deciding factor in switching from Mercurial. And then of course I've influenced people at the places I've worked to use it too, and so on...
"Better" is obviously a loose term as you point out; although I do think that there people who sometimes misunderstand Git. Like claiming it "changes" history and therefore it must be dangerous. I often find many people don't even know about the reflog, which I think is a crucial aspect of using Git and knowing that you're history is relatively safe once you commit. I suppose I'm hoping the article will dispel some of these myths, or at least paint a clearer picture.
And as with vim and emacs, you have people on both sides who vehemently claim that their tool is objectively better, when really it's a case of the two tools having different design goals and strengths in different areas.
The difference between "Mercurial vs. Git" and "vim vs. emacs" is that a person's choice of editor is largely independent of other people's choice in editors, and ideally your choice in VCS would be similar. But with a version control system you have network effects - if you want to contribute to a project using Git, you use Git, and vice versa. And because a few high-profile projects like Linux and Rails went with Git, Git had the stronger network effects, and ended up with a far greater share of users.
I could easily imagine everything going the other way if Linus or DHH had picked Mercurial instead of Git. So Git users need to stop assuming that the reason Git is so popular is because it's a better tool than Mercurial - it lets you do more things, yes, but that doesn't necessarily translate to "better." (Neither is Mercurial "better" than Git - it's more portable and the UI is smoother, but that also doesn't necessarily translate to "better.")