You absolutely nailed it!
This is why when people ascribe Success to any one factor, i simply roll my eyes. Personal Characteristics/Motivation, Timing, Circumstances, Random Chance etc. all have a role. The relative proportion of their weights will vary for any given event but all are necessary. As a learning and adaptive organism we do have some control over some of the factors i.e. ability to change their relative weights but everyone of them still count and cannot be neglected.
On the other hand, Failure is the general status-quo because it is so easy to be unaware/miss/neglect any single factor which might be essential (i.e. has a higher weightage) to achieve the goal.
Looked at from the above pov, it becomes clear that Failure is unavoidable and not something to be afraid of but is an essential learning method, thus; trial and error methodology. The importance of personal initiative and self-effort also now becomes evident; it is the only way we have to control and tame the various factors to the extent possible in our favour.
That's one of the fascinating things about software, we still have no reason to trust it to the degree that engineers who build bridges trust their work. There are almost never a backup bridge, and we quickly dismantle ferry routes as bridges are erected.
As developers and systems administrators we expect things to fail, if we're any good at our jobs, and implement redundancy, write restore procedures and in some cases create manual backup processes. Yet it's not uncommon to have multiple links fail and still bring down our towers of complexity and instability.
It is not that there cannot be multiple points of failure; it is that it takes just one point of failure to bring the entire system down. As long as there are dependant and moving parts failure will be inherent in the system; it cannot be "inspected/tested" away. Adding redundancy does not remove failure it merely transforms/postpones it. Failure is the "natural" state; we intuitively understand this through the concept of entropy always increasing (or more colloquially; "everything is going to shit") unless we do something about it i.e. expend energy and do work.
Therefore there has to be a single cause of failure, because all else failing the CEO has mucked up. And practically speaking there is probably a root cause somewhere closer to the problem.
"There are multiple causes of failure" style arguments are technically true, but also the sort of argument that people make when they aren't going to do anything to improve. There are many things that could change. There aren't many reasons why there was a failure.
> Why was the chain manufactured with a weak link?
I don't think it is feasible to manufacture a chain without a weakest link. The materials science requirements to produce truly identical links are extreme.
The people who truly improve systems are, in my experience, the ones that do consider multiple causes of failure. The ones who latch onto narrow chains tend to fix symptoms and then think they're done.
Making a strong chain is easy, finding a use-case for a strong chain is much harder. It doesn't matter how strong the chain is if there is nobody there who can pull it. And if you have a good use case and a person to pull it you can just get a standard chain, few fail because they failed to get a standard chain.
The "chain analogy" is just that i.e. a Metaphor. You need to map it to your studies in Systems Science and Complexity Science.
Start with the works of Henry Petroski. Then look at the works of Nassim Taleb, in particular Antifragile. Finally, do a search for "Failure in Complex Systems" and you get tons of journal articles one of which i have listed above.
Oh and btw, all these scholars consider Taleb like a wanker for a reason :)