In low latency environment, adding code is not the hard problem. Understanding the problem, the behaviour of the system, and what you program is really doing is the hard program. This leads to removing code, layers and complexity are more important and harder to achieve. To remove something you gain from static analysis, a minimum of side effects and clear relationships. You also benefit from a clear understanding of what the code is really doing all the way down to the CPU level. Without this you cannot remove things which don't need to be done and your code will be needlessly slower.
A simple example is the amount of garbage you are producing. One way to slow down a program is to produce lots of garbage. This not only cause GC pauses, which is what most developers are aware of, but also fills your CPU caches with garbage slowing down all your code (or any code which performances a memory access) by a factor of 2-5x in real applications. When you consider how much effort goes into speeding up a program by 2-5x by using multiple threads, this is not a trivial slow down. In the low latency space, it is not unusual to see processes which are made faster single threaded by using less garbage than they would be if they used every CPU.
In short, it is not how easy it is to add something, but how hard it is to remove something the computer doesn't need to be doing which matters.
Java has really grow up in this area since Java 5.0. It has been since then that you see more Java in the fast work load space. i.e. low latency and high throughput. Over time, Java will be used more and more in this space.
Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away.Antoine de Saint-Exupery
French writer (1900 - 1944)