That's not feasible for the millions of devices that don't have the resources for deploying GraalVM or GraalVM compiled native images.
The other thing to consider is that in many applications, nearly every single bit of i/o will flow through a buffer and cryptographic function to encrypt/decrypt/validate it. This is the place where squeezing out every ounce of performance is critical. A JIT + GC might cost a lot more money than memory safety bugs + AOT optimized compilation.
Native images are AOT optimized and use way less RAM than a normal Java app on HotSpot does. And you can get competitive performance from them with PGO.
Using a GC doesn't mean never reusing buffers, and Java has intrinsics for hardware accelerated cryptography for a long time. There's no reason performance has to be less, especially if you're willing to fund full time research projects to optimize it.
The belief that performance is more important than everything else is exactly how we ended up with pervasive memory safety vulns to begin with. Rust doesn't make it free, as you pay in developer hours.
The other thing to consider is that in many applications, nearly every single bit of i/o will flow through a buffer and cryptographic function to encrypt/decrypt/validate it. This is the place where squeezing out every ounce of performance is critical. A JIT + GC might cost a lot more money than memory safety bugs + AOT optimized compilation.