This is why I am so adamant about doing things properly. It is only when you know how to do things properly that you understand which rules are fine to break in which circumstances and, most importantly, what the potential consequences are and what risks those entail. In other words, you only know when to break the rules after you know the rules.

If someone demonstrates ignorance of the rules, I'm going to clue-by-four them with said rules. This is what I did in the referenced thread and I think I was correct in doing so. The OP hadn't demonstrated why the standard processes were insufficient for his needs. So, start from first principles.

I break the rules all the time. But, I know what can happen if I do and I have determined that the risks are worth it. There are many people who are better coders or DBAs or sysadmins than I am. But, being an effective team lead or a DBA or a sysadmin is much more than pure skill.

As for contexts - it's about risk management. If your business would completely collapse if a given machine dies, then you need to address that. The proper solution may be "Let's hope it doesn't." because the cost of securing that machine may be more than the cost of restarting the business. If it's not, then the proper solution is to secure the machine. This isn't about purity or anything. It's about business - risk analysis and proper mitigation. Nothing more.