That's kind of a misleading comparison. It takes that many characters to exactly reproduce the "hg id -i" behavior because hg chose a certain set of defaults that git didn't happen to choose. What if as an hg user I want the first 16 chars of the commit ID and don't want the "dirty +"? The hg command quickly starts to look uglier.
If you just want the current commit ID in git it's just "git rev-parse HEAD". Which is still longer and uglier than "hg id -i", yeah, but it's a fairer comparison.
True. My point is that Mercurial has a more coherent set of commands that usually, in my experience, give you an obvious way to do obvious things.
Git has (although it's gotten better!) functionality spread haphazardly across different commands, and many commands can perform several seemingly unrelated tasks depending on the flags. There are lots of command to give you the hash of current commit, all with different combinations of bonus features, and in this particular case we use describe (which really seems to be for finding tags reachable from particular commits) because it happens to support the right combination of features.
(Perhaps I should mention that I'm currently migrating to Git. Git is fine. Many things are better than in Mercurial, just not the UI.)
TBH I'm not sure I'd ever heard of "describe" -- I'd always used rev-parse to get a commit ID. But now that I'm trying it, it gives me a branch/tag name rather than a commit ID (either bare "git describe" or with the other arguments mentioned above). So...not really sure?
If you just want the current commit ID in git it's just "git rev-parse HEAD". Which is still longer and uglier than "hg id -i", yeah, but it's a fairer comparison.