I like the sentiment, but the article ignores that this approach may incur the price of adding complexity to the implementation.
Depending on your architectural constraints, adding an undo operation may not only be hard, it may necessitate changes which in turn make future changes harder as well.
Or it may not, of course - as usual it depends.
But even assuming that you are able to follow this advice, I assume (and have personally witnessed) another side-effect.
Just as people get accustomed to, and ignore, warnings, they will just as well become accustomed to being able to undo mistakes, and as a consequence become less careful about what they're doing.
One may argue that reserving warnings for only the non-undoable operations will improve their signal-to-noise-ratio and compensate for an overall gain, but whether that is true and worth the additional complexity is not black-and-white.
But even assuming that you are able to follow this advice, I assume (and have personally witnessed) another side-effect. Just as people get accustomed to, and ignore, warnings, they will just as well become accustomed to being able to undo mistakes, and as a consequence become less careful about what they're doing.
One may argue that reserving warnings for only the non-undoable operations will improve their signal-to-noise-ratio and compensate for an overall gain, but whether that is true and worth the additional complexity is not black-and-white.