This isn't a web thing, it's a technology thing. If you dropped a database via a command line tool or desktop app, you'd still lose everything. It's not phpMyAdmin -nor any other web app- being lazy, it's just how that technology works.
And I think the argument that you can't blame the users isn't fair because these are sysadmin tools - so you'd expect the users to know what they're doing.
"That's how technology works" because that's how the specific bits of technology we're talking about have been implemented. We make the technology, and we could make it work differently. There are cases where un-undoable commands are useful, but these cases are only a small fraction of the things we do on computers, sysadmins or not. Sysadmins may "know what they're doing" but they make mistakes like anyone else, and software should, where possible, be designed to reduce the impact of those mistakes.
Software is designed to reduce the impact of those mistakes - that's where back ups, file system snapshots and virtualisation / OS containers come in.
Some database operations do have an undo command per session; up until a commit is made. But it makes no sense to have an undo for drop database, which is why it auto-commits.
Sometimes the "undo" command needs to run a layer or two lower down in the stack than on the application layer. 9/10 times, there is an undo command (assuming the platform is installed correctly) - and as the author noted, he had a backups so that would have been his "undo".
So while I'm all for building safety nets and better tools; I also think the OP is being completely unreasonable expecting every sysadmin application to have an inbuilt "undo" command. Sometimes "undo" tools need to be worked into another layer of software lower down the stack - but just because they don't exist in the GUI frontend of choice, it doesn't mean that they don't exist at all.
But that's just my opinion as someone who also constantly makes mistakes hehehe
I think we can fix that! You're right that some things aren't amenable to a literal "Ctrl Z"---but I think Sacha's underlying point is spot on.
Many "irrevocable" actions could, with better design, be made made safe.
For example, Sacha's second story was where he accidentally deleted a production server instance. With a typical VPS, his configuration might be irrevocably gone, and he has to manually recreate everything under time pressure. But if next time he uses, for example, a Docker host, then such an error will be as simple to fix as deploying the same image again.
Another good example is Git. With most version control systems, "rebasing" is either unsupported or discouraged, and if you mess up, you can lose data permanently. Git's design is undo-friendly from the ground up: any commit hash encodes the exact state of your repo, including history all the way back to your first commit. So even if you rebase or force push and make a terrible mistake, you can nearly always use `git reflog` and get things back just as they were. Also, unlike some lesser VCSs, Git is transactional---so if you say "git pull" and then trip over the power cord while it's updating, your repo will still be in a good state afterward.
Technology that has a simple, explicit concept of state--such as Docker images or Git commits--is fundamentally nicer to work with. You can explore and experiment, and if things go wrong, you can roll back with confidence.
Well this is the thing, there are layers of software to recover (or "undo") from silly mistakes. Even with the phpMyAdmin example, he had backups. I don't think there's a lack of undo utilities, it's more a case that tools to undo sysadmin mistakes are often another layer of software lower down in the stack.
The docker example is a great one though. Lately I've been doing a lot of work with FreeBSD and using Jails (which, if you weren't already aware, are OS level containers for FreeBSD). And using ZFS to snapshot the Jail. I've worked with virtual machines before, but I just love the ability to take snapshots of an environment before making potentially dangerous changes.
It's probably also worth noting that some of authors examples also demonstrate why you should be using root access for every day operations.
The thing is, I do relate to the point he's making, but it also feels a little like he's blaming application developers for his own mistakes (using root access for general usage, not backing up config files nor snapshots, etc). So while I think it's great that tools are getting better and easier to use, we also need to be careful not to depend on these things to save us from our own laziness. Because that level of complacency will lead to more mistakes than if the tools required our greater concentration (as the adage goes: "the more idiot proof you make something, the bigger the idiot that comes along")
And I think the argument that you can't blame the users isn't fair because these are sysadmin tools - so you'd expect the users to know what they're doing.