Lots of actions are destructive and can't work with an "undo" quite so well as in that example. I would prefer to see a confirm diglogue for deleting an account, changing a password, that sort of thing. I would tend to avoid it anyway, as an undo button isn't something users are going to be looking out for in a web context.
Not to mention, that for many of these destructive actions adding a undo function often incurs in higher storage costs.
For example, in the case of deleting information, the easiest way to provide an undo function is to never really delete anything and just flag as deleted (something that doesn't free up storage, and if implemented without the users' knowledge, is abusive in terms of data privacy and ownership).
As for users not expecting the existence of an undo button in a web context, well, Gmail for instance has an "undo" link for lots of actions (archiving, moving to trash, etc.). I'm sure other web services provide similar things too.
What about this- clicking "delete account" loads a screen where the account is removed from the frontend, along with an undo button. When the user leaves the page, the account is really deleted. Can you see any problems with this?
I like the ingenuity but how would we track when the page has been left - conceivably I could delete an account on Friday then click undo on Sunday.
I guess if it immediately gets soft deleted and in a maintainance batch gets purged. Until maint runs the undo link could still work (although it would still only display until they left the page).
I still think a confirmation with "Don't ask again" is a much better solutions.
Power users see it once, understand what'll happen and turn it off, no annoying confirmation after they've identified as a power user.
Novice users would, I think, feel better about a confirmation than an undo - if you need an undo you've made a mistake and that's not a good feeling, if you see a confirmation the service is looking out for you.
Fair enough, you could be right - that's a well written counter-argument. However, while data might exist that users hate confirmation boxes, even those they can ask never to see again, and prefer undo, the cited articles doesn't contain any. It's not a Microsoft employee either, so the author doesn't have the sort of Windows data we often see in Microsoft blogs on UI. I'd also point out that the confirmation box example in his picture, for example, doesn't include an option not to show it again. It's also an undoable action as he points out, and I'm certainly not arguing that we should include both.
All that said, I can certainly see reasons for both - it's probably not really a black and white issue.