I have done extensive work with monoliths, and extensive work with microservices. I quite literally have never seen microservices be a benefit in the way you are describing, and if anything microservices can make the problem of robustness more difficult, because in many workflows there are one (or many) services that are critical. If they're down, everything is down, and if anything distributing these dependencies across different systems can make it more difficult to determine where the critical points of failure are.
As you point out, there is nothing inherent in a monolith that makes it less robust. I currently am building a monolith that is deployed on auto-scaling servers on a cloud provider, so if one server dies it just spins up other instances.
I have also done extensive work on both (I'm much older than the word microservices) and have found advantages to both approaches depending on requirements.
I've also found that most so-called monoliths still often end up breaking apart components anyway. I've only seen true monoliths as described above in the mom and pop type IT shops where there's only a couple support staff and they don't have the resources or experience to properly break things out into separate resilient components. And yes supportability is definitely a valid part of that design call.
Again that was just one example of a potential advantage to it while admitting there are trade offs. Others here have given better examples such as at larger orgs where multiple independent teams get involved with a single app.
As you point out, there is nothing inherent in a monolith that makes it less robust. I currently am building a monolith that is deployed on auto-scaling servers on a cloud provider, so if one server dies it just spins up other instances.