Again, not first hand knowledge, but my friend said that the approach to low latency Java was to disable the GC entirely, use object pools and to use a machine with enough RAM for N hours of continuous use before rebooting the VM.
It sounds like we’re talking about different problem spaces. Perhaps I’ve got the name wrong and it’s not “high frequency trading” but some other kind of trading 
What makes you call it “mediocre”? I’ve always heard of the GC algorithms used in Java VMs as being some of the best in the world, Azul C4 in particular.
The fact that it starts to severely under-perform under pressure like everybody else (including the BEAM of course).
Most GCs are of the “stop the world” kind, Java and Go included. However, BEAM’s is per-process.
So if you are willing to spend $5000 a month on a dedicated server, Erlang/Elixir is a much better investment. The spikes of lag during GC are much smoother there compared to a heavily loaded Java server.
But again, as said above – fine-tuning is the winning game in this area. I’ve seen several programming languages used for real-time work and they were mostly just fine because a team spent countless sleepless nights to hyper-optimize their system.
Well that just sounds like C/C++ or Rust with a Java syntax. 
Why use Java at all in this case?
I’ve used such a Java system first hand, for order routing. Essentially all memory was allocated at startup. The team who worked on it felt that in retrospect it may not have been worth all the trouble, though. It wasn’t particularly low-latency given all the work that went into it.
HFT systems have really strict requirements, 1ms is huge in that world. I worked on one where the authors spent time benchmarking and implementing their own spinlock because the standard ones had too much latency. In general you’d avoid passing data between too many threads because transferring data from a CPU core to another also adds latency.
I don’t think Erlang has a place in that world, but it would be a fantastic fit for higher latency systems. In fact I was working on one when I discovered Erlang, and that’s what lead me to learn it Our architecture in C++ used the reactor pattern and basically looked like a bunch of little processes exchanging messages already.