I have been using Mercurial for some years now and before that was on Git. Github used to be one of our remote repositories. The thing that Git excels is feature/bug-fix branches, which can literally be considered throw away branches. You work on one or more feature branches, independently and then submit a review request (github is just one option) and then have it merged against the actual release branch - all this without polluting the history of the release branch or without juggling with too many complex version control commands/tricks. Github wrapped around a lot of end user tooling around this concept (pull requests for example) and showed to the world how easy it is to accomplish this level of "parallel" feature work or bug fixing.

Coming to Mercurial, now that I have been using it for more than a couple of years, my experience is that, this workflow (which is now considered standard and well known through git and github) isn't possible to achieve. Mercurial's concept of branching doesn't fit into this scheme of things. They stamp each commit with a branch id and there's no way to erase that which effectively leads to a lot of issues if github has to support the model that I mentioned above - a model which is well known and popular at github. Mercurial recommends bookmarks for cases like these, which based on my experience and some of the discussions in mercurial dev list, doesn't work either. I hear they are working on a "evolve" plugin in Mercurial to sort out some of these issues. But overall, it's still very complex and requires a deep understanding of the mercurial concepts/commands to achieve what can be achieved in git pretty easily.

Given all this, I personally don't think it adds much value for github to support mercurial in such a way that the workflows remain (almost) the same irrespective of what underlying version control system you use.

Having only one VCS which everyone uses and knows is a huge advantage.