Sorry, sometimes breaking prod is your fault. As a senior engineer there is no excuse for forgetting a where clause on your SQL delete. And doubly no excuse for not having somebody else look at it.
Instead systems should be designed such that you can’t easily take them down due to operator errors.
Most of the tools I write require explicit --nodryrun if they're doing something dangerous or irreversible, and beyond that the really scary ones require some kind of acknowledgement that "THIS WILL TURN 1073 MACHINES OFF, ARE YOU CERTAIN, TYPE 1073 TO CONFIRM YOU WANT TO DISABLE 1073 MACHINES."
I want to meet your principal engineers who can fully understand a command's complete set of side effects solely from a bash snippet telling you how to invoke it!
Like yes, it is the principal's (well really everyone's, but sure insofar as someone is ultimately responsible, we can make the principal engineer responsible) responsibility to ensure processes are safe. But you can't do that by magically "refusing to engage in an unsafe process". Because it's difficult to know a priori if a process is inherently unsafe.
Usually you figure this out when something goes wrong, and then you take that learning from a postmortem/incident report and try to apply it to other similar tools. But no, I wouldn't blame anyone, not even a principal engineer whose job it is to ensure safe systems for accidentally fat fingering a dangerous command that they didn't know about.
They perhaps bear some responsibility for not having previously fixed it, but they bear approximately none for misusing a tool that makes itself easy to misuse.