There is nothing wrong with F#, the language (even though I don't particularly like its syntax), but clearly one has to account for the costs of reskilling the team on a new language, as well as a new paradigm, making a bet on a language with a still uncertain future (will it ever become a mainstream language?) and really non-existent tooling support.
Given that both C# and F# are general purpose, hybrid languages, I don't see a compelling story -- in 2014 -- behind F# that makes it such as huge deal as its advocates make it.
The onus is on them to bring convincing evidence to the table that, once factored in the risks and the costs that arise from the shortcomings, the benefits are still a good bargain in the real world, and with real people, outside of the easy fake example one finds on blogs etc.
The submission asks a question that many shops confront when F# is proposed. And the reality today is that many come to the conclusion that no, it isn't ready for production, for many of the reasons the submission notes. Your outrage will not change this reality.
http://neildanson.wordpress.com/2012/12/24/the-roslyn-incide...
Citation please? Writing a compiler in the language it's targeting is not always "best", but it is often done to reduce dependence on external toolchains and to flush out bugs in the language or compiler itself (since a compiler is usually a fairly complex program).
Every language has it's own benefits and drawbacks; the ML family of languages (which F# belongs to) was purpose-built for implementing compilers (and theorem-proving tools), so it would have been an excellent choice for implementing Roslyn, or at least parts of it.
IDE Support: Sure, the IDE support might not be quite as developed as C#. But frankly most refactorings are just pressing tab a few times with F#. Refactorings for C#/VB.NET are mostly workarounds for languages that require huge amounts of excess syntax. The IDE support for F# is still way ahead of most of the competition (particularly dynamic languages). The intellisense and error highlighting work fantastically well.
Options/nulls: Yes I suppose you still occasionally have to do a null check if you interface with legacy libraries. but I think having thousands upon thousands of .NET libraries means this is a worthwhile tradeoff. Plus you can use the TryGetX methods in F# far more nicely than in C#. http://luketopia.net/2014/02/05/fsharp-and-output-parameters...
F# missed by Roslyn: F# has had an open source compiler written in F# for years. C# is a ridiculous language to choose to write a compiler in. See http://fsharpforfunandprofit.com/posts/roslyn-vs-fsharp-comp...
What's coming next: F# is so far ahead of C#/VB.NET that this argument is ludicrous. Even if F# remained stagnant it would still always be better than C#. It has sensible defaults: immutability over mutability, functional over OOP, parametric polymorphism over inheritance, lack of nulls over null checks everywhere.
C# has poor defaults that are now irreparable due to the need to keep backwards compatibility.
F# is open to contributions now so I would expect some great things. Joinads, for example... http://tryjoinads.org/
Hiring developers is hard: This is a nonsense statement. Sure, if you want to hire 100 F# developers you might struggle, but you're going to struggle to find 100 good C# developers. Yaron Minsky from Jane Street reports hiring OCaml developers was "the easiest hiring he's ever done". If you tweet that you are looking for F# developers I know from experience that you'll get a lot of responses from very talented developers. Most places I've worked have a terrible time finding decent C# devs - interview:hiring ratio is around 50:1.