We just allowed some F# code into Kiln. On the one hand, it was vastly simpler than the C# code it replaced. On the other hand, we had to rearchitect our solution layout to handle changing the build order, which we in turn had to do so that the F# code could be sanely usable from the C# code and vice-versa, which in turn required writing a lot of call-site boilerplate and type converters (from C# to F# types). Add in that the CLR is simply not as optimized for F# as for C# (or vice-versa, depending on how you want to view things), and it's not exactly a situation where you can simply say, "Well, F# is better than C# at expressing this problem, so let's use it here."
I want to be really clear on this: I don't think these problems are any worse on the CLR than they'd be on the JVM or with native tools (e.g., OCaml calling C or vice-versa). In fact, they're better in many ways: you have the BCL for your primitives, rather than the native C ABI (for native), and you have a VM that is legitimately much less tied to an individual language than the JVM, which makes things like tail-recursive languages a lot simpler. But I think the right way to regard Foo# languages is more-or-less the same as any other language: unless you can write the entire project in Foo#, think hard about whether the cost of interfacing between Foo# and C# is worth it to your project. Most of the time, it isn't.