I still occasionally hear things about how the more academic-styled functional languages can't work in production, but Ocaml shows that it absolutely can work, even with high performance requirements.
Mercury also uses Haskell for their backend https://mercury.com/
I was fortunate enough to work at Jet.com before Walmart completely destroyed it, which was an F# shop. I really liked it, and I never really felt "limited" by it.
The stuff I was working on didn't have nearly the same requirements as high-frequency trading like Jane Street does though. I never did any super low-latency stuff with F#, so it's tough for me to say how well it fair with that kind of environment.
Would honestly be a lot more interesting than Haskell.
But I think what OP meant was more about the "functional programming" side of things than the "HM-typed" side of things. Naively, anyway, you might think that "the FP-style" of avoiding mutation and preferring recursion would require lots of garbage and high-latency garbage collection, copying, function call overhead...of course, that's not the whole story, but having Jane Street to point to as a crushing counter-example is nice.
It feels like the trend right now is to bolt on one or two "functional libraries" into your "normal" language and pretend that that's the same as writing Haskell or Ocaml. People have actually expressed such sentiments to me because Java has the optional type and a "map" function for the Streams API. When I suggest writing something in a functional language, the response is always "it's too hard" or "we won't be able to hire for that", as if engineers are somehow unable to learn new things.
I think it's purity that actually is a big difference, but OCaml isn't pure.
It complicates things that are simple to express in an imperative language