Because I really like the model/UX of the staging area. I'm not worried about the tool being simple; I use it every day, so it's worth learning inside and out.
It's a much nicer experience IMO to be able to work on various different pieces, then iteratively run `git add -p` or similar to stage individual files or hunks, verify everything I'm adding with `git diff --cached`, then `git commit` when I'm actually ready and happy. It lets me fix multiple parts of my project at the same time, without interruption, while still letting me compose my batch of changes into multiple, self-contained changesets.
`hg record` feels really limited by comparison, and rushes you immediately into committing your selected changes, and then further makes it difficult to selectively amend more (partial) changes to that commit afterwards.
One big idea that git should learn from Mercurial is history editing. git has only clunky, modal interactive rebase, and struggles with natural questions like "what is the child of this commit."
But hg makes it easy to walk up and down a stack, putting fixes in the right place.
At the risk of overreach, this feature would lead to better software. If your tools have better support for preparing a stack of commits, then code review will be easier, and software will be higher quality.
Same here. I used to regard http://jordi.inversethought.com/blog/i-hate-git/ as my hero, and then I had to start using git in a new gig, and never touched mercurial since. If the goal of using a vcs is to have meaningful atomic commits, nothing beats git staging area and interactive rebase.
Github won, so we're all forced to use git now, but mercurial is really a simpler interface and a more straightforward mental model.