reliability (Other) issues

The issue is really the extreme difficulty of programming them, especially for anything sequential (rather than combinatorial).

The issue is really the extreme difficulty of programming them, especially for anything sequential (rather than combinatorial). Yes, you can just put down a CPU core, but that's really slow compared to a real CPU and a headache in a lot of ways. (But still is a totally valid and used technique.) To give a concrete example, suppose you are doing some image processing and you need to write out something like a BMP image file from the pixel data in memory. Suppose, also, that it's dynamic-ish and you can't really precompute the header and just copy it around. This is a horrifying nightmare to do in an FPGA, generally involving writing a custom state machine and populating different bits of the structure on each clock and so on and so on. (This is not an arbitrary example, sadly; I've had to do almost exactly this.) You can do it but it's just plain hard. On a CPU you're done in five minutes, for a BMP file. Now imagine you want to write out a JPEG or PNG. On a CPU this is hard enough that you'll probably grab a library... and then still be done in about five minutes. Maybe thirty if something's unusual or you're being extra careful. Maybe a day or two if you decide to write it yourself (don't do this). On an FPGA? Holy hell you're in pain. You're either going to spend $$$ licensing something or you're going to be there for weeks. That is why there are jobs that FPGAs don't do. They're not technically impossible, they're infeasibly impossible. If it is your core business, yes, great, do them. But you'd never decide to stop making wasteful unoptimized BMP files on an FPGA "just because". It's a major chunk of work. But on a CPU, five minutes .