1. Control of memory layout is a big one. Ocaml has a very lisp-like object representation except without a cons-cell special case. If you try to directly translate some ocaml to rust (and the types are ok), you will gain from having fewer pointer dereferences and likely more cache-friendly shallow data structures in the standard library. There are some plans to make the compiler better for layout control (look for “unboxed types”)
2. Parallelism. There is currently a python-like lock so that only one thread may run ocaml at a time. There is a long-running project (multicore) to fix this
3. (Opinionated) lack of control of mutability: it is easy to have everything immutable or an object with fields that are always mutable, but you can’t easily have something like rust’s mut, which only sometimes allows mutation. Some changes to this may come with/after algebraic effects which come after multicore, but these are mostly about avoiding atomically where possible rather than making things const.
4. The compiler just isn’t as good as a c++ compiler and it needs to be better to undo a deeper stack of abstractions. I think it’s particularly bad for not really doing monomorphisation. On the other hand, it’s fast.
5. (Opinionated) it isn’t great for writing generic code, but maybe modular implicits will fix that.
That said, it is possible to write fast systems level programs in ocaml (you can be careful and avoid allocation in critical sections, or just have gc because for most systems it doesn’t matter that much. You can split things into multiple processes if necessary.) You could look at mirage for an example of something big and low level written in ocaml.
Having taken a stab at getting into that language, I can tell you the package landscape is freakish. Either you get on the Jane Street Train, or you slum it with packages from 2003 that don't have support (and probably dont build anymore anyway) Good luck getting things working on Windows. Honestly even Haskell is a better choice in that language space even though its getting eaten by Rust (and for good reasons).
I'm sure for some uses it would be fine. But typically the concern is garbage collection. Manual memory allocation and the ability to deal directly with pointers etc. is important for driver and OS development, as well as embedded systems work.
The GIL is not problematic if one uses processes, not threads, for parallelism. And for system-level programming it may be even better long-term solution as one can sandbox child-processes.
