I can see three obvious possibilities right off the bat (and I am sure there are more that even I could think of if I spent some time considering this):
Don't allow random users to run random commands, or commands that allow breaking out into an environment that will allow running random commands (such as an editor launching a subshell or saving files into /etc/cron.d), as root.
Don't allow automatically-authenticated (password-less) logins as root on other machines, even from "trusted" machines. If you absolutely must allow automatically-authenticated logins as root, make sure those logins use separate keys which are locked down to only allow exactly what is needed, and consider whether the flow of jobs can be reversed such that jobs do not need superuser privileges to run.
Have backups, and a disaster recovery plan. Make sure both are tested regularly.
Basically, these boil down to do your job as a sysadmin. A sane setup should employ all these tactics to protect against both the threat of an outside attacker as well as simple mistakes by otherwise authorized individuals or hardware/software failures.
Most attackers who are able to gain root privileges are more likely to use that to gain further access or to exfiltrate data, rather than to destroy the system. A destroyed system has no value to the attacker unless they are out to test your backups and disaster recovery procedures. A system that can be used as a springboard for further attacks has potentially significant value. Part of your job as a sysadmin is to ensure the security and confidentiality of the systems and data in your care.
rm
,cp
,mv
, etc. Closing down one particular program that is being run on the remote side is not the way to go. You need an in-depth security - which is an issue too broad for a QA site.