I would only use F# if I already knew it. Otherwise it just doesn't give any killer features anymore to justify the effort needed to learn it.
I don't consider things like no nulls and default immutability a killer feature. Also there is just a handful of F# jobs and they don't offer an outstanding salary for knowing F#.
F# async and parallel programming (Async.parallel, Agents/Mailboxes, Array.parallel.map, etc) are vastly superior to C# right now. Every latest C# iteration has repeatedly borrowed everything great from F#, that should be a sign alone that F# has tons of killer features (and continues to be ahead of the curve).
I picked up F# in about 3 months by reading a few books, then refactoring a C# library into F# (this taught me a lot of the interop quirks), and then doing a full project in as much of the F# idiomatic way as possible.
As far as jobs, I don't know anyone who uses the .NET stack that considers themselves strictly an "X" programmer. I've never used VB on a project, but I'd be pretty confident I could consult on a large VB project based on how much C# I've written. Mixed projects are really the best of both worlds anyway, learning F# will improve your C# simply because it teaches you new ways of reasoning about your domain.
If C# 7 ends up implementing Tuples, pattern matching, ADTs, etc... those are all bread-and-butter of F#, might as well learn how to use them ahead of time.
Parallel.x is already implemented in C#, I don't care who had it first. Akka.NET covers the actor model (note that Mailboxes do not support distributed scenarios). Those are not killer features (at least anymore).
I already improved my C# by reading about F#, there is nothing magical about deconstructible tuples, pattern matching and ADTs that needs too much time to learn. It's the rest of the "succinct" ML syntax that puts me off. That and lack of ReSharper.
