I don't think the risk is that bad. Especially if you are using .NET Core as a cross platform target most of the tooling is made for Windows anyway so is mostly unaccessible. VS Code for example works reasonably as good as any other VS extension - in my experience works better than the Java one. For a functional language it has a pretty good tooling story.

For the standard Docker microservice (e.g. ASP.NET Core, GRPC, etc stack) the tooling is more than adequate.

F# is mostly a superset of C# features these days with a much smaller lag in gaps than the other way around. On the protected members it isn't the biggest issue either - you can still override the method in your app code but it just changes it to public instead for the derived class. For interoperability to override C# classes it works and you wouldn't normally notice any difference; and in F# code you tend not to use the pattern anyway preferring composition to large object hierarchies. So your not blocked from overriding protected members on derived classes if you need to get a method overriden in a 3rd party C# library.

You may be giving the impression that there is missing capability from F# that will cause risk and block your project. Given I've used it professionally I don't think that's actually the case - it won't block you from developing anything that you couldn't do in C#. At worse case - if you actually want to use the really edge case C# features you can always create another project just for that bit of code and call it from F# code given the good interoperability. There's usually ways around this too.