First of all, you can lose local history in Hg too, by running 'hg rollback' and I _believe_ you can also do it with the 'rebase' extension (which was implemented because developers find that functionality in Git so useful). However, these are the exact same ways you can rewrite history in Git.
Second, the 'receive' setting is not for normal users - it is not run client side. It is an option for the people running the Git server and is not normally needed. If you trust your fellow developers enough not to commit something idiotic, then you can trust them to manage the head references properly. However, if your company has some super paranoid and poorly considered policy, then it is an option.
We do not enforce this at GitHub and not only has it never been a problem, but it has helped us help people solve issues that they do have - accidentally committing files you really don't want in there, or code with a license you actually cannot use or something. With Git it's relatively easy to fix the repository and force push the update and let your collaborators know this needs to be done. With Mercurial... I honestly don't know how you can deal with that.
Furthermore, it doesn't actually lose the changes, it just removes the pointer to them, you can push the old pointer back very easily. So, if you think this is an entirely 'bad thing', then I feel you misunderstand what it really means.
It's funny you say that I'm "not understanding what it really means" because that was actually the point of my criticism of Git.
Maybe it's just me that's stupid, but that doesn't explain the million blog entries saying either Git Sucks because it's impossible to use, or that they've had a eureka breakthrough and actually Git Rocks but you just have to understand that [reams of random gibberish] is what you need to achieve simple task A. The latter type of blog post usually has at least two comments pointing out that what the blogger suggests is both wrong and dangerous and suggesting two conflicting solutions to the same problem.
Apparently it's not as bad as it used to be. Again my knowledge comes mostly from blogs but every couple of months I read that Git is no longer perversely and unusably obscure. The fact that its unnecessary complexity is now being used as a defence against criticism doesn't encourage me to think that anyone is actually going to finally fix the human factors of git anytime soon.
Second, the 'receive' setting is not for normal users - it is not run client side. It is an option for the people running the Git server and is not normally needed. If you trust your fellow developers enough not to commit something idiotic, then you can trust them to manage the head references properly. However, if your company has some super paranoid and poorly considered policy, then it is an option.
We do not enforce this at GitHub and not only has it never been a problem, but it has helped us help people solve issues that they do have - accidentally committing files you really don't want in there, or code with a license you actually cannot use or something. With Git it's relatively easy to fix the repository and force push the update and let your collaborators know this needs to be done. With Mercurial... I honestly don't know how you can deal with that.
Furthermore, it doesn't actually lose the changes, it just removes the pointer to them, you can push the old pointer back very easily. So, if you think this is an entirely 'bad thing', then I feel you misunderstand what it really means.