It gives you a stack trace that helps you debug in seconds and when that is not enough a heap dump gives you enough information to solve the problem of a live service without having it down.
To use any other language for servers is madness. For clients I prefer C (with a tad of C++ for convenience like namespaces, string and streams).
I even hot-deploy to it with .dll/.so like I hot-deploy the classloader to Java for development speed!
Another quote you'll try to deconstruct but I know it to be true because I use it every day:
"While I'm on the topic of concurrency I should mention my far too brief chat with Doug Lea. He commented that multi-threaded Java these days far outperforms C, due to the memory management and a garbage collector. If I recall correctly he said "only 12 times faster than C means you haven't started optimizing"." - Martin Fowler https://martinfowler.com/bliki/OOPSLA2005.html
There are plenty of practical solutions to the safe memory reclamation problem in C. The language just doesn't force one on you.
From epoch-based reclamation (https://github.com/concurrencykit/ck/blob/master/include/ck_..., especially with the multiplexing extension to Fraser's classic scheme), to quiescence schemes (https://liburcu.org/), or hazard pointers (https://github.com/facebook/folly/blob/master/folly/synchron..., or https://pvk.ca/Blog/2020/07/07/flatter-wait-free-hazard-poin...)... or even simple using a type-stable (https://www.usenix.org/legacy/publications/library/proceedin...) memory allocator.
In my experience, it's easier to write code that is resilient to hiccups in C than in Java. Solving SMR with GC only offers something close to lock-freedom when you can guarantee global GC pauses are short enough... and common techniques to bound pauses, like explicitly managed object pools, land you back in the same problem space as C.