If you adapted it for software, it's almost the same as saying "don't focus too much on the happy path, make sure you limit the blast radius for the failures cases", which just sounds like sensible advice.
You really have to take the adversarial mindset when thinking about large scale systems like this, to make sense of how they can break.
Thinking about the failure modes is the default mindset of a traditional engineer. Unfortunately software engineers in general are entirely too focused on the happy path and nothing else.
Focusing on anything besides the happy path requires the approval and support to do so from other teams and their respective management and QA.
No, they'd rather not coordinate any of that and just play the blame game.
Many workplaces employing software engineers are actively hostile towards any kind of engineering. I have a very hard time believing anyone writing code is sloppy on purpose. Incentives are often very misaligned. These are pretty much always organizational problems.
Instead of immediately blaming software engineers, you should consider questioning whether it ever makes sense to have non-technical leadership in charge of them. Most places where "real" engineering is done don't have idiots at the wheel.
When I write software, every line of code is accompanied by the thought "I'm a blackhat hacker, with execution thread. How do I leverage this line of code?"
You really have to take the adversarial mindset when thinking about large scale systems like this, to make sense of how they can break.