Erlang’s magic comes from being limited in what you share between threads. This simplifies the design of an efficient GC (each thread can be GCed separately), and it simplifies the work to get back to a consistent shared state after an error.
OCaml 5 chose to have little restrictions on what you can share between threads. Having a GC simplifies the implementation of parallel data structures. Moreover OCaml 5 makes no distinction between local and shared state, the GC assumes that any value is in want of being shared between domains. Design decisions that follow from this choice, such as having a stop-the-world minor collector, work against goal 1.
As for 2., in the presence of shared state one must be careful about how one cleans up the mess after an error occurred. This asks for good resource-management features and a good story about exception-safety (see the example of Rust, which we have already discussed). Unfortunately, in OCaml you have to count on programmers’ discipline for this, which they have to discover the hard way because there is no consistent story being told about it. My understanding is that OCaml 5 was designed around a more defensive view of errors than Erlang’s let-it-crash. I do not see it (edit: the defensive approach) as realistic, and my past work on recovering from asynchronous exceptions at the OCaml workshop 2021 is relevant as it was also meant as a way to reverse this view (with the intuition that if one shows that it is possible to recover from asynchronous exceptions, then it also tells you to which extent you can recover from exceptions in general). On this topic, the following discussion about Eio is relevant: Understanding cancellation (in eio).