Glad to hear it. The main problem I noticed the last time I used F# is that it generates more function calls, along with more heap references (vs stack-allocated structs) for things like boxed values, generators, etc to do simple tasks compared with C#. Is it the case that you can optimize all this out using parts of the language I don't know about?
F# supports value types just like C# does, so I wouldn't expect more boxing on the F# side. Some types like tuples that are used more in F# than in C# are reference types, so you might want to avoid them in your inner loops, but that generally just means writing F# that looks a bit more like C#. Likewise, as to the number of function calls, it's probably a question of style more than features, though you can do things like use the `inline` keyword to make sure that particular functions always get inlined at call sites, which can be a big win in some cases (it also allows you to write type-safe generic math code, which is an oft-lamented unsupported scenario in C#). Lots of people are making good use of F# in contexts where heavy computational requirements exist (e.g. finance or scientific computing), but I'm not too familiar with projects using it where more real-time requirements exist (though I think someone's in the midst of porting Quake III to F#, so it'll be interesting to see how that goes).
The RyuJIT project shows that .NET JIT performance is still on the radar, though I haven't seen any indication that SIMD is on the roadmap.
To your final point, it's clearly true that C# is familiar to a wider variety of developers than F# is. However, I've been impressed by the uptake of some F# libraries, like FAKE. F# reads so mush like pseudocode in some cases that it's easy for people to buy in even if they're not especially familiar with the language.