Some product vendors will decline support if you use F# instead of C# or VB.
You will get told to reproduce the problem in C# or VB, otherwise the ticket gets closed.
Those apps you list are also not cross platform as I mentioned in my comment. They are also not the apps you typically code in Ocaml either which is where the comparison/comment was coming from I feel. For cross platform development and some of the software typical when comparing F# to Ocaml, F# IMO is perfectly fine and on par with C# (sometimes better depending on the problem space).
For vendor specific issues F# ports pretty well to C#. For the very odd time you've proven a bug in F# its pretty easy to whip up a quick C# project to give to one of those "vendors" (half an hour/1 hr maybe to build a repro you would need to do anyway). To be honest most of the time they don't help you with C# either - support sadly in my experience is only on paper and never covers you fast enough when you need it. It's just a tick in the box that you have the risk covered should you ever need to resort to this; which many projects never do.
I get your point for some applications, and if you are doing those kinds of apps fair enough. Use the right tool for the job. But I personally think for languages in the JVM/.NET camp the risks of project failure are overblown and aren't as big as people make them out to be especially if they are pragmatic rather than academic and/or syntax heavy. Given they can piggy back on the bigger ecosystem to avoid getting stuck for edge cases.