> talking about adoption and name recognition among non-engineers
Agree that non-engineer recognition it is a poor way to run projects but sadly that matters to some engineers I've talked to as well + comfort zones. Having F#/Scala experience means they could always find a C#/Java job and that depends on the city/industry you are in as an example.
> I see no compelling reason to adopt it over JVM
That's an opinion preferring the JVM over the CLR which is a stating potentially a personal preference? Technically both are capable so I think that's a moot point - the CLR is pretty good and Java on some things is playing catchup (e.g. value types). JVM is good too but the differences won't probably mean much to most projects.
> Scala probably has at least twice the adoption levels of F#
Scala has many good points and some use cases better than F# for sure. However to play the other side some reasons I can think of on the F# side include that default web performance favors ASP.NET Core (even on Linux) from bench marking by quite a bit over say Spring Boot/Play. The HM type inference also is a plus for F# IMO (as it is for OcAML) and it leans to being more FP first giving the FP benefits quicker with less fuss. The multi threading (Futures/Async-Await) API seems more ubiquitous in the .NET space last time I checked, less LOC to use, and is exposed on a lot more libraries/clients/etc as a first class citizen. Its also IMO a lot easier to make your whole program async and has more inbuilt language support to avoid overhead. Important things in hosting an API I think especially around thread use/scalability. F# has things like value types, compile time generics, tail recursion (for FP), Spans, and other CLR features etc which allow that low level performance tuning where required - it seems to be closer to the CLR than say Scala is to the JVM. Something I do like, just like C#, is to compile it to self packaged bundles for multiple targets (ARM, MacOS, Windows, etc) in a smaller bundle than JVM based apps.
Popularity is a proxy for risk. I would assert it only matters IF the base isn't mature and it doesn't have an ecosystem to piggy back on. Popularity is a proxy measure for "something's probably missing" which for say Scala/F# isn't really the case given their ecosystems depending on your use case. OcAML is probably less popular than F# as an example but for certain use cases could still work - sadly it doesn't have that ecosystem to piggy back of and that is a factor for some teams (not all but many I've been in). F#'s been around for awhile and reasonably mature as a base.
Scala is a good language too. But I wouldn't dismiss F# in these comparisons either. There's nuances that need to be considered. Where you want a language with the crisp FP first feel/benefits of OcAML with an ecosystem just large enough to avoid risk F# is a good compromise and will work quite well. TL;DR Nothing's perfect, more similarities than differences, and as long as you aren't blocked language isn't the big factor in project success/failure that many make it out to be.