It is standard practice to kill and restart Java processes in high availability systems
As someone who works solely on HA systems, I can assure you that this is not a standard practice. It is in fact the opposite of what 'HA' means and would be considered an unacceptable showstopper in any project. Our server platform consists of Java, C++, Fortran and AIMMS, and out of all these the only components which require a separate daemon to monitor their status / restart on failure are the C++ ones. This is not a negative commentary on C++, merely a byproduct of the higher bar of code quality required to achieve graceful fault handling in that language. The Java components running out of containers never need to come down unless they have an actual memory/resource leak induced by the code, something so ridiculously easy to spot and and address it would never have made it past round 1 of QA. Perhaps you meant 'It is standard practice to kill and restart poorly written processes of any language in high availability systems', but you would still be wrong because if you have such components you do not have an HA system.
Sometimes it is the only way to fix specific problems which are quite difficult (or impossible) to find and fix programmatically.
Complete nonsense. Aside from the fact that I can use a debugger, profiler, JMX console and heap/thread dumps to diagnose literally any problem on a live Java process, if a developer ever said the above to me they would be immediately reassigned to intern-level shitwork and fired at the nearest opportunity. 'bounce it once in a while' is an utterly unacceptable solution in HA regardless of language.
They don't understand what the JVM has to do to keep the magic happening
I don't think you do either. You seem to think that there is something about the JVM that inherently leads to long uptime issues. This is a function of bad code, not the language in which it was poorly written or the container under which it is executing. Profiling Java applications for deviations in resource usage / behavior is so easy that we had an intern set it up as an automated post-build step using only tools that come standard with the JDK, It took her about a week. There are some valid criticisms of the mis-use of Java (or any language for that matter), but your whole stability argument here is just completely bogus.