For writing any application, not least server side, that needs to scale with the number of cores and processors. Pure functional programming is stateless (does not rely on shared resources), and therefore does not run into deadlocks, race conditions or corruption as traditional imperative parallel programming. Similar things can be done with imperative/OO languages, but requires much greater discipline, or emulating functional constructs as with Parallel Extensions in C#. And beware: not everything can be done in a purely functional manner, especially since the CLR and runtime libraries is OO by design, so deadlocks, races and the rest don't go away entirely.
For addressing business domains with heavy mathematical abstractions, such as finance, insurance or engineering. Sooner or later, second- and third-order functions tend to creep in as essential abstractions in those domains. F# isn't pure functional, but is close enough to express such abstractions well.
For addressing domains with strong safety and correctness requirements. The F# strong typing model may not attract e.g. the Ruby crowd, but for certain areas, being able to reason about correctness with the support of an expressive functional type system can be essential. I'm doubtful that correctness proofs will ever achieve penetration outside academia, but inferencing as one tool in an arsenal of automatic and manual program verification suite should provide significant benefits that are hard to emulate by duck typing languages or OO with functional programming bolted on.
That said, I believe functional elements such as those introduced in C# will play an increasingly important role to meet any uses for F#, and possibly undercut the position of F#. This depends on whether a sizeable F# developer community can grow quickly enough.