1) The .git directory doesn't play nicely with mono-repos. Since all files are just hashed files that live in the .git dir, knowing which files in there are part of a subtree is hard. On the other side, Mercurial .hg dir uses a tree structure to track files, so you can do things like NarrowHG[0].

2) As well, Git has multiple client implementation (like git, egit, jgit, etc...). Adding new features is a bit more complicated as all the implementations need to add them before they can be more widely used. Mercurial has one implementation that everyone uses. So new features are easier to add.

3) The .git structure is simple, which is great, but it's become the API for git in a way. While mercurial explicitly says you should never rely on the structure of the .hg directory. If you want to interact with the .hg dir from other software, you should either issue 'hg' command or start up a command server[1] to talk with it. So it creates a cleaner API barrier. Because of this, the Mercurial team can make changes to the .hg dir to better serve different needs (like those of a mono-repo), without breaking the world.

[0] https://bitbucket.org/Google/narrowhg

[1] https://www.mercurial-scm.org/wiki/CommandServer