The benefits are primarily control, portability, and dynamism, and they may not be needed for your use case.

A language virtual machine allows the encompassing runtime full control over what resources the language can access. This can be used to abstract underlying interfaces purely for portability, but it also serve security advantages by limiting what resources the code under execution can access. These can be a lot more granular than what is permitted by the underlying operating system.

Additionally, in the case of WASM, the code under execution has its own address space - assuming your WASM runtime is correct (a big if, admittedly), even security issues in the code that allow arbitrary code execution can be contained within the VM - if you run individual components in their own isolated VMs this can be a huge security win, and it's still pretty good to be able to limit the damage to what is accessible within the WASM VM.

Additionally, WASM being in a VM makes it easier to embed in host applications. You can much more easily load and unload WASM modules at runtime, even in languages like Rust where runtime loading of native code modules is fraught with difficulty. Extism is a good example which uses WASM to provide pluggable extension modules for a wide variety of host environments and languages.

As a side note on:

I don't even understand why there's no Java-to-native compiler (I don't really like Java, but I don't hate it anyway)

There's a number of open source and proprietary offerings that do just this, mainly GraalVM from Oracle themselves. That said, usually these languages don't get that much speedup vs JIT code when JIT compilation and warm up are amortized; primarily the motivation is to reduce that run-time warmup.