Maybe if you had to say "DELETE" out loud when hovering over the "are you sure you want to delete this?" confirmation to verify it.
It's an interesting example of how a seemingly "anti-usability" feature can actually help usability by preventing a wrong action.
Usability is mostly about making it easier to do the right thing, but sometimes making it harder to do the wrong thing helps too.
I think that's almost useful, but better if it displays and asks you to echo a key fact that helps you recognize an action as important and/or confirm it's what you intended. Typing is fine; no need to do voice recognition.
* the number of machines your action will affect (for cluster management tools)
* the amount of traffic (qps, Mbps, etc) you'll affect (for routing changes, taking down servers, etc.)
* the amount of data you're deleting (some rounded form is fine) in files, bytes, database rows, etc.
* since someone else mentioned deleting a github repository: the repo's number of unique commits (ones not found in the repo it was forked from), issues, PRs, or even just stars/forks.
* the number of people you're adding to or removing from an ACL group / mailing list
Plus the image of the silence in an office being punctuated by the occasional "DELETE" or "CONFIRM DROP TABLES" is hilarious.
Congratulations, you named the very reason this technique is effective. I am not being facetious here.
The whole idea is to make the user perform disruptive, unfitting actions -both in the mind and physically- to improve chances of catching errors.
First, to both make the mind "shift gears", or perform a "context switch", with all the related cache-flushing and prediction-discarding and all that.
Second, to activate brain regions that were hitherto suspended; the ones associated with other senses and skills, in particular with vocal skills. Fleshing out abstract concepts into concrete words helps catch mistakes, just like putting abstract feature requests into concrete diagrams or code helps with catching errors or inconsistent expectations & assumptions.
I was thinking more about systems where no lives are at stake, and there I think there's no need to change modes, one can be DISRUPTIVE ENOUGH by using the same IO channels, which are quite flexible already.