The issue you will face with using a relatively niche language is development velocity, i.e. the speed at which you can deliver product features.
Niche languages generally have a smaller ecosystem, less documentation, more bugs (due to fewer eyeballs looking at the bugs), and a smaller pool of developer candidates. All of which means projects in those languages will take longer to build than the same project in a mainstream language. If using F# means projects are going to take 2x longer to write because the limited ecosystem means you wind up having to build everything from scratch, or because you have to rewrite a large portion of the code to workaround a quirk in the type-checker that was never fixed, those are project-killing problems.
I'm not saying you can't make it work, but those are the hurdles that you'll have to overcome just to be at the same level as a mainstream language. You have to be absolutely sure that the advantages that F# brings is more than enough to overcome that.
I think we should be careful about throwing around numbers when we have no idea of the actual situation.
For example, if we look at the Total Cost of Ownership of the project, it may turn out that after the ramp of onboarding and initial development has been climbed, it's relatively much faster and cheaper over time to add new features and maintain an existing OCaml or F# project, because its language features highly encourage maintainability and 'clean code'.
It may also be the case that because of type system features like exhaustive pattern matching and abstract types or units of measure, or compile-time code generation, F#/OCaml prevent and save the project from many bugs and incidents which might have plagued the C# project.
Also it may happen that the fact of using OCaml/F# may attract tech talent who may not have otherwise considered your company.
There are many variables and the answer is not really clear-cut.
F# is helped by the easy interoperability with C#: you can call any C# library without problems (you might however want to write a small wraper to reduce friction with F#).
I guess that comes down to the real speed impact. A factor of two will kill the idea of using F#. A factor of 1.2 might be okay. It all depends on the pay off. If the bug rate is as reduced as I have seen with my own tinkering then it will be worth rebuilding somethings from scratch.
But I don't know how you justify the risk when there are other mainstream languages that do the job.
Sadly i don't have a link, but i read somewhere about a project written in C# by 5 devs in 7 years. Same project gets rewritten F# by 3 devs without prior experience with it in 2 years. Yes it is easier to rewrite than build from scratch but still pretty impressive IMHO.
Niche languages generally have a smaller ecosystem, less documentation, more bugs (due to fewer eyeballs looking at the bugs), and a smaller pool of developer candidates. All of which means projects in those languages will take longer to build than the same project in a mainstream language. If using F# means projects are going to take 2x longer to write because the limited ecosystem means you wind up having to build everything from scratch, or because you have to rewrite a large portion of the code to workaround a quirk in the type-checker that was never fixed, those are project-killing problems.
I'm not saying you can't make it work, but those are the hurdles that you'll have to overcome just to be at the same level as a mainstream language. You have to be absolutely sure that the advantages that F# brings is more than enough to overcome that.