Some comments about the “Advantages of OCaml over Rust”:
Yep, this will most probably remain the case, since nested pattern matching is incompatible with abstraction boundaries (unless they somehow manage to integrate matching against the Deref target, but this would lead to more implicit calls to Deref::deref, and for some people this can be annoying, when auditing someone else’s code, for instance; imho this could be easily fixed with a lint to help spotting it);
The lack of currying in Rust is indeed very annoying! (long live eta reduction); however, once existential types get stabilized, writing zero-cost higher order functions within traits should become quite feasible
Imho this is only a result of the two previous points, since besides the lack of currying and the lack of nested matching, Rust let us write functional style quite easily;
So, I agree that Rust forcing us to write very explicit code can indeed hinder egonomics when writing code that can afford some loss of performance. And in that case, it is my opinion that other languages may indeed be best suited than Rust.
Moreover, I like the idea of using a functional language such as Ocaml or Haskell, since their functional style will often give as much safety as Rust (it should be very close to coding in Rust without &mut) at the cost of some performance.
Performance-wise, there is a big difference between Rust and Ocaml, since the latter, much like Python, does not support built-in parallelism, due to a global lock, and OCaml parallelism thus requires multi-processing or FFI:
Ocaml: Concurrency and Parallelism
To directly answer your question:
Except for the following caveat:
OCaml has runtime exceptions, which makes handling them in an exhaustive manner harder than with Rust’s monadic Result
I answer that using Ocaml is a perfectly reasonable thing to do.
Note that this will add FFI-handling overhead to your code, which is usually the opposite of ergonomic.