That observation checks out. About a decade ago, one of my former coworkers areas of interests was making Java applications and frameworks that didn't use the any additional heap beyond app initialization. This was apparently for embedded/low power devices. It was neat to hear about as a C++ dev, but I'm not sure how much of a business or technical advantage it had beyond that.
Job pool, memory safety and lower development costs versus C++ tooling.
"Why we chose Java for our High-Frequency Trading application"
https://medium.com/@jadsarmo/why-we-chose-java-for-our-high-...
i'm developing apps that do real-time audio and video and any allocation or anything that may end up in a system call directly or indirectly (for instance accessing swapped or mapped but not yet loaded memory) on the hot path is a complete no-go and will instantly cause very audible glitches for audio, and visual frame pacing issues
This DAW uses a mix of Java and C++ for good effect, so at least some people are rather happy with the approach
https://www.bitwig.com/
AFAIK all the core of bitwig (e.g. what has the hot path) is a separate native process with no java in it, communicating with shmem or sockets with the java gui
I have not said otherwise, "This DAW uses a mix of Java and C++ for good effect".
The point being that it does not need to be a black and white approach, one language to rule them all, as many tend to advocate for.
The big one that comes to mind is MISRA.