Presumably if performance were a key concern you wouldn't have used OCaml to begin with.
Anecdotally, I once worked at an Ocaml trading firm - where microseconds could matter! - and at least at the time, folks there weren't particularly interested in multicore. We have async/lwt already, and we spun up multiple processes for parallelism. A 10% performance drop for multicore support that we didn't need would have been unacceptable for us.
Claiming a functional language is as performant as a systems language is a very big claim.
Ocaml is used in many performance and latency sensitive domains as a minimal amount of research would show you. Here's an example:
https://www.janestreet.com/tech-talks/building-an-exchange/
It's also got a reputation for pretty predictable performance characteristics, fast compilation and ease of writing correct and concise code, properties C++, for example, does not necessarily share. Part of this is because the compiler is comparatively straightforward in what it does (and same for standard library), with the flip side that you leave some performance on the table. But that might not be a bad trade-off given that ocaml generally seems to be within a factor of ~3x of C++ (which can probably easily baloon up for specific problems, given that ocaml has e.g. poor SIMD and machine size int support). So you probably wouldn't want to write AAA game engines, crypto libs or numerical kernels in it. But my guess is that a language with those characteristics (and much faster iteration times) translates to better real world performance for many other types of tasks.
Claiming "within ~3x of C++" answers your question. For the problems I work in (some of which you mention) even a 5% is a major deal. 300%? That’s just crazy talk and a non-starter.
That’s what performance means and why most language benchmarks are usually useless: people writing them have no clue of what are the requirements of many fields.
I assume you mean 105% and 300%? And what are the 105% that are a major deal – the runtime relative to what the hardware could theoretically do? Or 105% relative to what you can get out of C++?
Likewise, there is an endless amount of compilers in research written in OCaml.
Last time I checked, anything related to compiler toolchains used to be considered systems programming.