What does FP do well? (was How to get functional software engineering experience?)

[Scott Finnie]

Claus Reinke wrote:
> The ground is better prepared than ever. It remains up to you to 
> decide whether you're confident enough to use FP, without needless 
> hype, and just for the many things you know it can do well.

As a naive but interested newbie, I'm very keen to understand those
things that FP does well - and just as importantly, those things it
doesn't.  (I'm coming at this from use in an industrial context).

Based on (_very_) limited experience so far, I get the feeling that:

 . FP is well suited to transformation-type problems - i.e. those that
   can usefully be viewed as transforming some input to a required 
   output.
 . FP - or at least Haskell - is not so well suited to reactive, event 
   driven, parallel systems: i.e. those that can usefully be viewed as a 
   CSP system.

Please don't flame if this is off-base, I'm trying to get a handle on
things.  This is based primarily on Haskell; I realise Erlang's primary
domain is telecoms, which implies it does address the second category. 
Assuming that's so, are there extra concepts in Erlang that make it
suitable for such problems?

Thanks,
Scott.