Speaking as someone who went from Haskell to ML, I don't see the loss of type classes as a terribly big deal. The implicitness of type classes is useful “in the small”, but the global benefits of a real module system in terms of type abstraction and separation of concerns outweigh the local benefits of the occasional shorter definition using type classes. In addition, ML modules have structural signatures, which makes it easier to retrofit existing modules to new hierarchies. For comparison, try making Haskell's existing Monoid class a subclass of Semigroup, without recompiling any code. :-p
My general experience with OCaml hasn't been great. To be blunt, it seems sort of like a less-well-thought-out version of Haskell.
The biggest downsides that I remember were:
* IO sequencing via (;) : () -> () -> (). This is sort of a relic from before we had monads, and is relatively pretty clumsy.
* No type classes. "Generic" operators like (<) work by binary comparison (!!!). This is terrible and leads to nonsensical ordering semantics for non-trivial data. There's also no generic (+), (), etc. There are separate functions for ints and floats. Again, clumsy.
Questionable unboxing techniques. On a 64 bit processor, ints are 63 bits because ocaml has to use a bit to tag them as non-pointers. On the other hand, Haskell differentiates boxed/unboxed values statically at the kind level, so there are no weird pointer tagging tricks or related overhead.
I have limited experience with OCaml, so take this with a grain of salt. I also think OCaml has valid use cases. In Jane street's case, I can see OCaml being a better choice than Haskell for the reasons I mentioned. The people there definitely know the advantages and disadvantages of both. One of the hardest interview questions of my life was a very interesting Haskell question from Jane Street!