1. Lack of documentation. While there is some documentation on the web (and the free translation of the O'Reilly book is quite good), it's probably too little, too late. There are very few books published in English, and one of the most accessible of them (Practical OCaml by Joshua Smith) is IMHO one of the most poorly-written programming books I have ever seen.
2. Haskell seems to be getting most of the attention in that niche. (This is arguably the biggest factor.) Its community is somewhat small, and it doesn't have the general presence, marketing, word-of-mouth, etc. that Haskell does, and it had years and years to do so.
3. There are lots of cases in the OCaml implementation where they could have made it much, much more friendly to people trying to learn its typing, but didn't. ("Error: This expression has type t but is here used with type t" is baffling.) The exception system has a lot of rough edges, too - Debugging a program throwing the exception of "Not_found" without any context provided is rather irritating.
4. It cuts more than a few usability corners for sake of pure speed. Some people consider this a feature, but I don't like it as a default.
5. Its support for concurrency is not great (though this may have gotten better lately).
OCaml is one of my favorite languages, but there are a lot of ways it could be made nicer. While I don't use the .NET languages, it's at least reassuring to see that other languages are using the good ideas from the ML family.
But the performance is very good, and the type checker is awesome. I like it (in my experience on toy problems).
You mentioned performance vs. usability - Not_found is vague for a reason; it's the way you find out if a key is in a hashtable (no null or Maybe return). Exceptions without payload are apparently very efficient in Ocaml; they're used often in "non-exceptional" cases in the library.
I understand why they do it, but I don't like speed over usability as a default. I would rather be able to tighten up the execution via a few declarations, compiler options, etc., if necessary, but have the default be maximum flexibility, detail for debugging, etc.
I like the typechecker mostly because it's easy to use a few type annotations to do things that would otherwise require loads of unit tests.
My rule of thumb these days is, "Python is fast enough, without proof otherwise."
F# gets the full backing of the world's biggest software vendor in VS 2010...