Except that HFT firms don't call themselves HFT any more, they re-branded to ultra-low latency trading. And FPGAs are the norm now, not the exception. Sure, Java still has its place, but implying that it is anywhere in the hot loop of a contemporary ULL system is wrong at best and disingenuous at worst. I mean just read the abstracts from this years STAC conference. https://www.stacresearch.com/spring2020
The biggest manifestation of this is that FPGAs really struggle with sizing. Say there's a given market event that produces a very obvious opportunity, but it's not so obvious how big that opportunity is. Archetypical case is when the price changes, and there's a new level formed on the book.
It's almost certainly the case that adding an epsilon of liquidity at the first position of the queue is profitable. What's harder to determine is where the breakeven point is. Should you add 1 lot? 100 lots? 10,000 lots? That's a lot more complex because you generally have to be sensitive to the typical sizes in that particular market and that particular time, as well as how strong the level formation event was. E.g. was it in response to something that looks like a very big order, or just some random liquidity depletion.
What happens is that the FPGAs know they should quote an epsilon, but can't really confidently quote anything bigger than that. So if the right answer is a thousand lots, the FPGA will quickly capture first queue position with something like a hundred lots, then the software-based players with take the rest of the 900 shares for themselves.
What you see with FPGAs is a segment that makes very consistent, very good money relative to the volume that it executes. But fails to capture the sizable majority of the market share.