The problems with F# are that .NET was originally Window's only causing the creation of a separate run-time in Mono, there were breakages when .NET moved from .NET Framework and Mono to .NET Core (now .NET 5), problems with messaging F# as a C# replacement, biased perspectives of F# as a Microsoft product, Microsoft's lack of investment in and marketing of F#, and F#'s overall ecosystem. There's also the push and pull that comes from some developers wanting to make F# into Haskell, whereas I think that's against the natural settled state of F# as a multi-paradigm practical language.
One can write F# basically as one would write Python, yet F# comes with a host of improvements over Python. One could even go full OOP in F# like one would in C#, again with improvements of conciseness and readability. With F#'s functional paradigm but non-insistence on purity, one gets a language that allows you to write beautifully correct code that works and doesn't fight against you. I use F# in my side projects and also some small work projects, and when using F#, it feels like I'm just translating a specification into code where when done, the code just works.
Unfortunately, the F# ecosystem is not as coherent as others. Probably the comparison I would make is to Elixir. Although I'd argue Elixir isn't as nice of a core language as F#, Elixir's ecosystem and coherence across that ecosystem is very nice and yields a great development experience. The Elixir community has rallied around certain ways of doing things and frameworks where it feels F# is a little more spread out.