Maybe this is not that much relevant for DVCSs but in 'classic' VCSs such as SVN an 'obliterate' command would be quite useful, think about the case when someone accidentally commits something highly sensitive (such as private keys) to version control. People make mistakes all the time, either way.
Re:Why I Switched to Git From Mercurial
by charlesmarshall on Monday May 17, 2010 @12:12PM
(#1354660)
you can use commands like git filter-branch & git rebase to change your history - http://www-cs-students.stanford.edu/~blynn/gitmagic/ch05.htm...
"git rebase" on its own does not permanently alter history. It creates a new branch that looks like a new history, but you can get back to the original history.
"git gc" will prune the unused old histories for that permanent effect.
even "git gc" will not do it for a while. the old history will still be referenced from the reflog for some time (I think default is 30 days)
Most destructive commands in mercurial do create a backup first. However, some command, for which all we know, could have been written by a third party, didn't. That's why I suggest that you read the docs for a command and test it out on non-important data before applying it to your only copy of a repository. Someone could just as easily create an extension in git that forgets to create a backup as well. What happened to the author is entirely the author's fault.
Ability to control and be able to reverse any changes you make to the source code tree is an essential feature of version control system - precisely because you don't know in advance what will work and what won't. The fact that people are not used to that simple idea just shows how broken are most of the other tools out there.
There is no reason not to want an unlimited undo for almost everything, especially today when disk space is so cheap.