I would argue that F# is a better business programming language for a lot of reasons.
First, the type system is great when it comes to modeling the problem and communicating that model with non-technical project managers because writing good data models often means you write clear code that's idiosyncratic to the language. My experience is non-technical people understand clear data models and pipelines and those are two areas where F# code reads very clearly.
If OOP is your thing, I can argue it's a much better OOP language than C#. From a SOLID and Design Patterns perspective, the language has been streamlined to encourage a good OOP style by default. Design Patterns are simpler (Factory, Builder, Decorator, Adaptor, etc). Dependency Injection is very natural and implementing fluent APIs is a lot simpler.
The biggest benefits come from maintaining good hygiene. You're a lot less likely to have null reference exceptions or introduce invalid states. Race conditions are harder when most things are immutable by default. You're also less likely to encode things poorly because your type system sucks. You'll think more carefully about how you write loops, ifs and switch statements because the compiler catches and prevents you from doing boneheaded things. It's also has features that prevent you from accidentally adding cyclomatic complexity. For example, lower-level modules are not allowed to refer to higher-level modules. It's also harder to accidentally make functions recursive because it requires a special "rec" keyword.
I realize people dismiss hygiene, but this stuff really goes a long way to help manage complexity when it comes to growing and maintaining applications over long periods of time.
I'm not going to claim it's great at everything. It's a wonderful back-end and business language, and it's fantastic at modeling business objects and records. However, the tooling isn't there for doing WPF applications. Also, sometimes you come across issues with libraries that work well with C# defaults but not F# defaults. For example, F# properties tend to be read-only by default, so libraries that hydrate objects with data don't work unless you explicitly make those properties writable.
Nevertheless, if nothing else was an issue (buy in, training, etc), I'd opt to write the business logic in F# 9 times out of 10 times and save C# for the front-end (tooling).