I believe he is referring to the git workflows and tutorials that encourage rewriting history in a potentially lossy way.
Mercurial can do the same sort of history rewriting, to a point, but it is not the default workflow and requires that you explicitly enable that functionality. Even then, when you push a modified history to the central repository, you have the old history around still. Whether or not this is desired is up to your team's workflow, but it does make it harder to lose something.
not exactly, i'm referring to the difficulty in undoing a committed merge if you don't use the --no-ff flag as suggested in this article.
i believe this is precisely why they suggest using it - because on private branches you can undo merges in much more destructive ways which are not viable on a shared repo - they suggest using --no-ff for when you merge in a feature branch
(edit: it is precisely why and there is an article linked from the original discussing the pros/cons of merge and rebase)
i'm using it in the sense of English - its not a specialist term or a piece of jargon. i.e. I mean 'undo', 'revert', 'reverse' - unpick just feels more appropriate because its often a fiddly process if you are doing anything more than a simple revert or back-out type operation.
Mercurial can do the same sort of history rewriting, to a point, but it is not the default workflow and requires that you explicitly enable that functionality. Even then, when you push a modified history to the central repository, you have the old history around still. Whether or not this is desired is up to your team's workflow, but it does make it harder to lose something.