Hard macros (thinks like BRAM, DSP slices, etc) are blocks which do a fixed function, are faster than reconfigurable logic, and take up less silicon area - they trade off configurability for speed; let's explore that.

A multiplier is a multiplier is a multiplier. You can spin your own, but it is so common that every FPGA vendor says, "If you need to multiply, you can use this block." You want to write code that is general:

A <= B * C + D;

And have your synthesizer go, "This is a multiply accumulate! I can fit that into the following blocks: Look up tables or a DSP slice. I'll use the DSP slice - it is faster and smaller." Note that you didn't directly call the DSP slice, you just said "multiply". It doesn't always work this way, but that's the goal.

Not every FPGA has a dual core cpu - the Virtex-5's and 6's started that trend with a PPC block, and it really hit its stride with the Zynq-7000 (when Xilinx switched to ARM cores and brought the price down significantly). Again, if you're doing things a CPU can manage, you CAN do them with logic, but why not use the embedded core?

The addition of the ARM cores was a brilliant move by Xilinx because a number of embedded systems out there used FPGAs for fast response, high speed interfaces, high speed datapaths, and as glue, but many included a separate processor to handle "housekeeping" tasks.

Xilinx noticed this, and said, "If you want, you can choose the chip that has a processor core in one corner instead of reprogrammable fabric there." Bam, tons of sales - because now instead of two chips, I need one. Integration.

They're furthering their exploration of that interface with HLS and their newer toolsets. The idea is to make the algorithmic division between the two things null - you can seamlessly switch between control and data dominated computation.

But let me take one step back.

What's the difference between a state machine and a counter?

Nothing. They're a cloud of 'next state' logic, a current state, and an output based on the current state and/or the current state + the current inputs (Mealy/Moore/Medvedev). The 'next state' logic happens to also follow the rules of arithmetic, which is what you're interested in when you're using it as a counter, obviously. But it's a state machine.

So what's the difference between a CPU and a state machine?

Again...nothing. A CPU is just a complicated state machine (or a set of interacting state machines).

To dislike hard macros which are fast and common is to not grok FPGAs. To say you work with FPGAs professionally but you consider them a dead end, when they're built out of the same logic and blocks that underlies everything that's ever been done with a digital computer is...confused, at best.

We're one step "above" transistors in the abstraction hierarchy. But those transistors would implement things like counters (assuming you're not building an analog computer!), and you'd be right back to an FPGA (well, an ASIC, so YOU get to choose what blocks get included or not!).

A lot of people who design ASICs do it from HDL's - they even use synthesizers! But the synthesizers are targeting a library of parts for a silicon process. The only difference is that the blocks being targeted on an FPGA already exist - you can't move a block over to get better timing like you can with an ASIC, or widen transistor ratios to drive more current, etc - you have to use what's on them.

So...yeah. FPGAs use the fundamentals of all computing directly, they're not a dead end unless we all decide to switch back to analog computations or quantum computers or something, and the hard IP is really important.

Even if spinning an ASIC decreases in price to a few grand (crazy hypothetical), they'll be programmed like you programmed an FPGA - full of the same primordial soup components right above transistors that does all the work in the digital abstraction.