I dunno, we have a lot of libraries and frameworks who make it their purpose to efficiently run code on either a CPU or GPU (or TPU, if we're talking about things like tensorflow); a FPGA is conceptually just an extension of that except, ofc, that on-the-fly FPGA recompilation usually outweighs any performance benefits you'd get from using the FPGA based hardware accelerator, so the only reasonable uses are one and done layouts with occasional patches/updates. If we could get an FPGA gate pipeline that was as efficient as the modern shader pipeline, I think what we could use them for could expand greatly - imagine a tracing JIT that could dynamically load hot sequential code into an FPGA to speed it up, the same way we can load matrix ops into a GPU today.
With where FPGA toolchains are today, it just doesn't work _because_ the compilation process is so bad and slow, and nobody except the engineers within Xilinx and Altera even have a reasonable shot at making it better since both the compiler and the compilation target are closed. Part of it is simply that these compilation passes aren't really configurable (beyond expressing layout and pipelining preference) - if I could get near instant bitstream generation in exchange for 30% extra space used, I'd use that setting for all but my final builds, and strongly consider invoking it at runtime.