If you have a team looking for a functional language on .NET it's amazing - so I don't dismiss it - it's just a very niche thing on .NET platform.
What objective measure can someone use to determine whether F# is the best choice?
What is possible however is to first analyze the core attributes of the techs which are relevant for the project and team such as: good supported libraries for the problem, support for immutable data-structure, expressiveness of the type system, experience of the team with the tech etc. You can then decide which tech fits better the environment. If still undecided you can try to build a prototype on a short period (at the risk on giving up on technologies which are hard to learn but could be rewarding on the long term).
I used to be a very big fan of a certain functional language, and invested serious time and effort into projects in that language, but hindsight tells me every single time it was a mistake. It was a mistake because if you cannot hire people to do the work then the project dies when it needs to grow.
People used to do very big projects in COBOL, which most hacker news readers have never even seen, and as someone who did some COBOL, I can confirm that it was absolutely terrible, but the projects got done and by and large with less tech stack Jenga or superfluous trash that infests so many projects today. COBOL died when the majority of people moved on, not because st80, pascal, ada and C were better, but because the industry switched to platforms where the dominant languages were day one different: pascal and C. Mac, Windows, the Unix workstations.
Maybe those platforms used other languages because they were better. Certainly I can’t imagine the Mac built with COBOL, FORTRAN, bcpl (worked for amiga, somewhat), etc. but the dynamic of leaders is different from the dynamic of followers.
Your second point is about platforms. A FP language hosted on a popular platform has a lot to gain. That's the Clojure story. Rich Hickey tried different solutions / languages before but only Clojure was successful enough. Because it's tied to the JVM.
But... nowadays most popular FP languages are hosted on a popular platform (JS/Web, JVM, .Net) so if a FP language builts a community that is big enough (no need to be big like Python) it will be sustainable.
Last comment: if you think about sustainability on the very long term, such as COBOL projects, then choosing the default language of the platform (JavaScript for the web, Java for the JVM etc) may be wise (because the platform is more likely to die after the other languages). The truth is that most software project don't have such a long life so it should be only one criteria among other for the choice.
So to conclude given a good choice for a platform (BEAM for distributed systems for example) I think languages do matter, because they offer different trade-offs (less state bugs with FP languages for example).
The whole mental framework of hiring for a language comes, I think, from HR/business people assuming that programming languages are like natural languages and that language experience is a central, fixed component of a candidate's identity.
In large parts of the industry we simply don't believe this at all, interviews are about algorithms / problem solving and experience filters at senior levels are about business problem domains. Getting up to speed in whatever language is just part of onboarding.
I love F#, but don't think it's ideal if it's shoe horned into a C# project. You then have this boundary layer you have to maintain.