I would be interesting in learning more about the "easy to reason about the complexity" part of OCaml. The problem I'm having with Haskell isn't that it's too slow, but that it's so high-level and gets so aggressively optimized at compile-time, that the performance of the resulting binary has performance characteristics that are unpredictable and non-deterministic. Performance can regress between GHC releases, for instance. This just seems to be a problem of high-level programming languages in general, they're really slow until you start optimizing them at compile-time. And with each one of those optimizations, you get another layer of indirection with regards to how disconnected the speed of the code you wrote should be vs. how fast the final product actually is. Haskell has no business being as fast as it is already, but GHC gives it to us at the price of long compile times and very fuzzy performance properties that are very finicky and expert-friendly.

The problem I see here is just the unsolved computer science problem of how to reduce the complicated, drawn-out, and error-prone job of a C programmer into the succinct job of a functional programmer without fundamentally pretending modern computers work in a way they don't.

The complain list on Ocaml is almost always smaller than on Haskell. It might be easier to just fix Ocaml's issues and use it. If not permanently over Haskell, then temporarily until Haskell can get their more complex issues solved.