While I also don't know the complexities of what Rob has done in terms of programming the FPGA, as an IT bizdev guy, I have lived through the arguments between general CPUs vs. FPGAs vs. ASICs since the 1990's.
As I understand it, ASICs and FPGAs can do many many tiny processes with a ton of small IO gates, while general CPUs can do very few but very powerful processes with fewer IO gates.
Of course, as CPUs have become more powerful every year, they can handle more multi-threading, but the numbers they post are often illusory, as general CPUs use a number of tactics to make it seem like it's handling several threads, but in fact is staggering them off of a limited number of cores (1, 2, 4, 8, 16 cores, etc.), and staggering processed data through a limited number of IO gates, usually in a round robin fashion, though sometimes giving some processes more "turns" than others to pass through the gates (a kind of QoS tagging in a chip). The fact that with a general CPU, those commands for what tactics to use to give the high count levels of multi-threading are controlled by software, which in turn can have hiccups in talking to the CPU, can compound very tiny levels of timing accuracy and speed.
When timing is much more critical, I imagine (and I have no real understanding of this except for major assumptions), having an actual physical high count of low cpu cores (hundreds, thousands, even millions in some FPGAs), and having hundreds or thousands of actual physical IO gates, allows for much more accurately timed processes. That picosecond, nanosecond level of accuracy over time is, I'm totally guessing, what Rob needs to ensure transient tap lengths are delivered accurately to achieve natural sound as close to the original analog wave length as possible.
The second advantage of FPGAs vs. both ASICs and general CPUs is that the management of the gates are field programmable (hence the name, field programmable gate array), meaning, they can have very specific functions, thus reducing bloat or unnecessary code in the chipset. Which, if I understand the marketing correctly, makes it as close to a true SoC as you can get in a single affordable chip.
Ultimately, general CPUs can do the same thing as FPGAs, but since general CPUs simulate high numbers of cores and high numbers of IO through simulation, and it's controlled by software, it's much harder to control the accurate timing of data. General CPUs are just not designed for that type of process.
-----
I could be totally wrong, since my connecting of assumptive dots leading to my above conclusion comes from my bizdev work in the IT industry. Maybe Rob's reasons are completely different, but though this might perhaps be the reasoning for it.