I've written a number of IP cores with FPGAs over 10 years ago and the sad fact is that the same problems and criticisms that led me to forget about using them anywhere than at some big company are still very relevant today. Problems include:
* Hostile toolchains for independent developers / engineers. Lack of reasonably useful toolchains including simulators, synthesis tools, the works. iVerilog has been lame before in my experience, for example.
* Expensive hardware that's artificially inflated in price due to lack of commodity concerns (perhaps lack of competition in general)
* Toolchains unfriendly / bad UX for traditional software developers. I read a Linux Journal article with a Python-like HDL featured - myHDL and its traction is what I suspected it would be - irrelevant to anyone but hobbyists, and hobbyists have basically zero input into the industry unlike software's dynamics. After working with different compiler vendors and doing some research in the space (GPGPUs completely destroyed the market like I figured back then because software developer use cases of hardware tend to be very narrow uses of FPGA / ASIC capabilities - parallel processing or custom FPUs for boutique DSPs being typical), I've seen rather little progress compared to the leaps in software productivity. Even the recent Scala-based Chisel language seems a bit trite as well and more research-ware that won't be adopted by manufacturers probably because...
* Most FPGA and ASIC targeted use cases for HDLs are primarily for hardware engineers first most, not people that are software engineers first. When people get specs on hardware, nobody really cares about the HDL code written as much as whether the SOC has a lot of test benches and they look at the block diagrams instead of the HDL typically and things tend to be developed typically as black boxes due to how IP cores work (per industry conventions).
* Compilers for hardware languages have had tons of issues for a long, long time because expressing bit math and signals (especially the analog extensions to VHDL and Verilog) have been really cumbersome with imperative style languages. Historically, we've gotten far more concise, legible results with language clarity by using conventions from Matlab and R than with C and Ada, but Verilog and VHDL are just too damn dominant and most experienced electrical engineers that are hardware gurus really do not like to learn a lot of new languages and semantics unlike how software developers tend to behave typically.
However, I've always felt that hardware engineers and software engineers should talk a lot more, and the ever-increasing gap has been a disappointment for me. I'm totally on-board with a lot of testing for software, but at the same time I understand that software is typically designed with the expectation to change things frequently while hardware is typically written to be reliable-first and to go through insanely rigorous testing because you cannot patch hardware. Most IP cores that are distributed a lot have at least 2.5 times as much test benches / harnesses as the code to actually do the work. Hardware has much more rigorous specification designs than software typically though, so this is possible at least. Haskell's QuickCheck would be totally helpful for how a lot of hardware is tested because nowadays you can't test all the combinations of signals on, say, a 128-bit bus in a reasonable amount of time. So test benches are full of tons of statistical functions and are sometimes even generated with machine learning techniques to exercise the most likely to fail use cases and states. This all goes out the window if you switch languages typically. That kind of attention to testing is almost unheard of in software in my experience.
A trivial-seeming example of how HDLs are hostile to software developers is the difference when you write a switch statement in C versus in an HDL (tremendous apologies, I haven't written Verilog in 10 years):
switch (input) {
case b'10:
output
vs.
switch (input) {
case b'10:
output
Omitting a default case causes a latch to be produced by the compiler, so the two are VERY different and will punish software developers that like to use shortcuts (my Perl background bit me real hard trying to do shortcuts in the Verilog compilers I used before - I was even more surprised to see my C-style macros failing after only 2 levels of indirection to try to make my cores more configurable, forcing me to rewrite my cores often). Unlike in software where something like whether a switch statement becomes a jump table or a series of if statements isn't typically make or break, in hardware the difference between a single clock cycle being used up or not is massively important.
After basically yelling at my compiler and tools oftentimes for doing things that defied their documentation enough times, waiting hours for place and routes to finish (they ARE NP hard, after all), and uncovering so many edge cases in FPGAs that required use of clock trees and manual refinement of the resulting FPGA image file, I realized that this just wasn't going to get much better of an experience because these levels of concerns are what hardware engineers are responsible for tuning themselves and you just can't abstract and delegate it away.
I asked my boss back then why Intel shouldn't enter the market and he responded "because if it's commoditized, the entire industry will lose all their margins because the market for FPGAs is primarily large company hardware engineers." It took over 10 years later for Intel to finally buy Altera it seems... and in the meantime we had an incredible number of things happen across the spectrum while FPGAs are still practically the same user experience and fundamental architectures (nothing like SMT happened in FPGA land really, no really revolutionary compilers to make writing hardware super easy).
There's a gazillion more reasons why we'll see more people using the Raspberry Pi and Arduino for learning to tinker with hardware, and Xilinx, Altera, etc. have always been the way they are now, so my decision to just never go back to the fun world of FPGAs seems to have been justified, sadly.