I'm a bit torn on this subject.
I spent the last 3 years of the 'hands on' part of my dev career swapped over to F# from many, many years of writing predominantly C#, and it was a fantastic experience. Don Syne's main pitch these days is to think of F# as a productivity language first, and a FP language second, and I would support that view. Much of what F# pioneered in the .net space has indeed come over to C# in recent versions, but as a result C# syntax has grown significantly, and I see engineers having to talk each other out of 'bad practices' to use new idioms. You don't get that in F# - the 'right way' is just the default to start with, and you have to go out of your way to do the reverse (mutable code, side-affecting structures etc...). Rather than FP, just think 'nicer C#'.
That said, as a manager now, I'd have to be completely honest that it does present some real issues, principally around recruitment and/or ramp-up. I personally thought the cross-skilling was easy (~2-3 weeks), but even allowing for that, it's still an impost, and there is an entirely legitimate view that it's just one more thing engineers have to think about. F# hasn't been ported to Roslyn (Roslyn can't yet cope with tail calls I believe), which then excludes some tooling (like static analysis). And Microsoft themselves were gently dissuasive when the subject of using it for a particular project was brought up by the team.
So ultimately I think the question comes down to productivity and cognitive load. F# does a fantastic job (I think) of reducing those, but at the cost of biting off some up-front cross-skilling. The latter cost is very real and tangible, and the former is quite a lot harder to pin down and measure.
Ultimately in my case the engineering team came to the conclusion they had enough on their plate to worry about already, and I can't help but sympathise with that. That said, any code I write at home, or just to prove a point, I write in F#. I'm never going back.
Piers