FPGAs are essentially interpreters for hardware!

The architecture is like dedica

ted ASICs, but to get rapid development, and you pay a factor of ~10 in frequenc
y and a [don't know, at least 10?] factor in power efficiency.
So take any task where dedicated HW can massively outperform CPUs, divide by the
FPGA 10/[?] factors, and you'll probably still have a winner. Typical qualities
of such tasks:
Massive opportunities for fine-grained parallelism.
(Doing 4 operations at once doesn't count; 128 does.)
Opportunity for deep pipelining.
This is also a kind of parallelism, but it's hard to apply it to a single ta
sk, so it helps if you can get many separate tasks to work on in parallel.
(Mostly) Fixed data flow paths.
Some muxes are OK, but massive random accesses are bad, cause you can't para
llelize them. But see below about memories.
High total bandwidth to many small memories.
FPGAs have hundreds of small (O(1KB)) internal memories (BlockRAMs in Xilinx
parlance), so if you can partition you memory usage into many independent buffe
rs, you can enjoy a data bandwidth that CPUs never dreamed of.
Small external bandwidth (compared to internal work). The ideal FPGA task ha
s small inputs and outputs but requires a lot of internal work. This way your FP
GA won't starve waiting for I/O. (CPUs already suffer from starving, and they al
leviate it with very sophisticated (and big) caches, unmatchable in FPGAs.) It's
perfectly possible to connect a huge I/O bandwidth to an FPGA (~1000 pins nowda
ys, some with high-rate SERDESes) - but doing that requires a custom board archi
tected for such bandwidth; in most scenarios, your external I/O will be a bottle
neck.
Simple enough for HW (aka good SW/HW partitioning).
Many tasks consist of 90% irregular glue logic and only 10% hard work ("kern
el" in the DSP sense). If you put all that onto an FPGA, you'll waste precious a
rea on logic that does no work most of the time. Ideally, you want all the muck
to be handled in SW and fully utilize the HW for the kernel. ("Soft-core" CPUs i
nside FPGAs are a popular way to pack lots of slow irregular logic onto medium a
rea, if you can't offload it to a real CPU.)
Weird bit manipulations are a plus.
Things that don't map well onto traditional CPU instruction sets, such as un
aligned access to packed bits, hash functions, coding & compression... However,
don't overestimate the factor this gives you - most data formats and algorithms
you'll meet have already been designed to go easy on CPU instruction sets, and C
PUs keep adding specialized instructions for multimedia.
Lots of Floating point specifically is a minus because both CPUs and GPUs cr
unch them on extremely optimized dedicated silicon. (So-called "DSP" FPGAs also
have lots of dedicated mul/add units, but AFAIK these only do integers?)
Low latency / real-time requirements are a plus.
Hardware can really shine under such demands.