I would encourage you to read Tell Above, and Ask Below - Hybridizing OO and Functional Design by Michael Feathers and a follow up by Jessica Kerr.

The thing is, true OO is orthogonal. C# is primarily a Class-Oriented language, so you generally still follow a more imperative flow. As Alan Kay noted, "OOP to me means only messaging, local retention and protection and hiding of state-process, and extreme late-binding of all things. It can be done in Smalltalk and in LISP." With agents (MailboxProcessor<'T>), F# can actually achieve true OO.

And now I've realized that I've not answered the question directly. If you take for granted that pure FP is the best default in F#, then I believe it follows that it is best to stick with pure FP facilities by default (modules+records+unions+functions). I would only use object-oriented facilities (interfaces+classes+methods) when leveraging the OO paradigm for a specific reason, or when I have an otherwise specific need. This makes sense to me in practice as sticking to functional facilities allows you to avoid lots of type annotations, makes code more portable between OCaml et al, have functions available to pass around (can we easily pass instance methods in F#?), can curry function calls (methods typically use tuples and thus won't be curriable). All this should afford us more idiomatic F# (that is, as soon as we can establish what we collectively mean by idiomatic F#!)

I know Michael's question is not aimed at me, but I do feel I have useful input.

My mental model is that the primary thing we're after when programming is producing code that we can most easily reason about. Pure functional programming gives us precisely that and is adequately supported in F#, so that's why I consider it the best default. Sometimes it is inadequate however, and we have to selectively use other techniques.

One concrete example of when to abandon pure FP is when you need an abstractly stateful machine to represent a plug-in or an IO device. Anything whose representation must be opaque is therefore best represented with an interface or abstract class. Abstractly stateful machines use late-binding to become one of the most powerful and flexible tools in software development, but are accordingly the hardest to reason about. This is combinatorally problematic when you have such machines that are related recursively and bidirectionally (typical of OO software). This is why OOP is a bad default in my opinion, but also very appropriate when you need exactly it.

Another concrete example is when you need fast computation over a large data set. Imperative procedures become indispensable when you need operations that scale over very large data. This set of idioms has been known as procedural programming, array-based programming, or as data-oriented programming. (I particularly like the data-orientation paradigm because it places specific emphasis on being cache-aware, among other things). This is great stuff for writing a physics engine or transformation pipeline. It uses the computer's panache for in-place mutation to achieve maximum speed by leveraging locality of reference and direct data representation. However, the use of mutation and lack of data abstraction makes the code harder to reason about. This, like OOP, makes it a bad default IMO, but invaluable where appropriate.

Another example is where you need to implement a ton of very similar features without having an explosion of code to write. I typically approach this with declarative programming. Declarative programming gives us a higher, more customized semantic context in which to write code. Once we have lifted our programming context out of general-purpose computation, we can very quickly implement the features that are closed (algebraically) under the lifted context. An example is a game's special effects written in XML and interpreted at run-time to produce cool magic spells. Double bonus when you can actually write a code generator that produces machine code (VM or otherwise) that leverages data-orientation techniques for maximum performance. The downside is that you either end up with an interpreter that is slow, or a code generator that is a lot of work to implement - not to mention more code to step through when debugging. Haskell monads are a nice balance of perf and implementation difficulty, but due to laziness are very hard to reason about in terms of performance, and do have limited expressiveness compared to external declarative implementations.

The last example I can think of right now is when you are in an optimization phase and you need to get more responsiveness out of your program. Transforming your code in hotspots to use in-place mutation can improve scaling significantly. This probably doesn't require further explanation as it is likely obvious as to why optimization is desirable only when required.

Cheers!