Domain Specific Languages, parsing, new language creation in general, rules-based systems, highly-scalable applications, cross-language compilation.
As an example of the last item, the Web Toolkit allows you to write one, er, server page with F# on it. Kind of like C# or VB with old-timely asp pages, where the code and the html was all together.
The cool part is by flagging the methods to either run on the server, client, or both, you just write code to do stuff -- a server method can call a client one which then can call a server one, etc. The system figures out how to do the work. And even cooler, everything is in F# -- the F# language abilities are programmed so it automagically turns the F# into Javascript when the page is rendered.
Cool stuff indeed. You can do the same in Scheme -write stuff to be run in server or client very easily and make them both interact, and also have Scheme being compiled to javascript - using HOP ( http://hop.inria.fr/ ).
If I'm in .NET land, I'd prefer to use F# absolutely whenever I can. It's not like there's big important things it can't do that C# can.
The biggest thing to me is that if software systems keep getting more and more complex, the need for language-oriented programming will increase along with it, and combinator libraries have been found, over the last 20 years or so, to be a good tool for creating embedded domain-specific languages.