It's like the actor model. It's better for an actor to just fail instead of trying and recovering. Just make sure another actor can take its place and that the failures are isolated from each other. By using this method, you avoid the enormous cost it takes to make something very reliable. It's the 80/20 problem.
Let's say we have a service than whenever it handles a requests has a 80% chance of succeeding and a 20% chance of dying. The easy way to lower the chance of failing is to just have two services that handle the same request. If one fails, the other one might succeed. Using this strategy, we've now just lowered our failure rate to 4%, instead of 20%, with very little additional work. The cost of making only one service have a 4% failure rate (instead of 20%) is so much higher than a service that has a 20% failure rate.
This is the perfect analogy, imo, for mainframes. So much effort and cost has gone into making these things super reliable. But it turns out, we don't actually need a super reliable system. For example, NYSE ditched it's mainframes a long time ago, because just using x86_64 and Linux to achieve the reliability needed is much cheaper and easier. And you would be hard pressed to find a company that needs as much reliability as a security exchange. If mainframes aren't worth it for NYSE (the mainframe apologists would say that NYSE is exactly the kind of company that needs mainframes the most), then they probably aren't worth it for anyone at all.