A hallmark of this book is a very pragmatic, Rosetta stone approach to F#.
Since F# lives in .Net, and .Net is inherently object-oriented; it makes sense to understand something of the mapping that takes place behind the scenes when F# code is mapped into the .Net world.
Many of the interesting new features introduced into C# are actually hand-me-downs from FP (functional programming). This includes generics, LINQ, anonymous methods, lambdas, type inference, etc.. Since many programmers need to use C# in the work-a-day world, it makes sense to understand the functional elements of C# by seeing them in a functional language like F#, where they can be seen in their purest (least hobbled) state. Once these concepts are understood, it is then much easier to understand how to wield these tools effectively in C#.
That said, there are also limits to how much functional programming can be done in C# (and how effectively it can be accomplished). This book clearly demarcates the boundaries of what is (and isn't) feasible in C# vis-à-vis functional programming.
One of the things I liked best about this book is the discussion on why functional programming makes code easier to read, write, and verify. This discussion does not appeal to what might be (for many) inaccessible theory (i.e. denotational semantics, category theory, etc.). Instead it is demonstrated in amazingly simple, straightforward ways! This discussion is very effective.
Another facet of this book's approach that I applaud is the demonstration of lambda calculus. Why would a practical book dabble in theory? There's actually a very pragmatic payoff in doing this: functional programming has a lot of underpinnings in lambda calculus. Those that have been exposed to lambda calculus will feel right at home in F#. Those that haven't are likely to feel more "culture shock" when being exposed to concepts like currying and lazy evaluation. Functional programming really does represent a substantially different way of thinking about computation.
This book also features an excellent discussion about design patterns; comparing and contrasting how they are implemented in OOP (object-oriented programming) versus FP. Some classic design patterns in OOP essentially come for free in FP (e.g. the "visitor" pattern).