People seem pretty happy when Go and Rust do the same with static linking, advocating how great it happens to be.

You can't be as aggressive at removing functions in Java than in Rust though since it's dynamic dispatch (e.g., if you use toString once in your code, you need to keep all implementations of toString which are reachable even if users don't use reflection).

.NET's trimmer/linker deals with this quite well, only referenced or otherwise observable .ToString() implementations are rooted.

Without it 1.6-2MiB-sized AOT binaries would not have been possible (most space is occupied by standard library/runtime bits and GC)

Except that is what jlinker, and GraalVM/OpenJ9 (among other AOT toolchains) do in practice.

Static linking in Go and Rust includes compiled code only for the target platform. It does not include compiled code for every possible architecture, including 32-bit MacOS and Solaris on PowerPC.

Solaris... now thats a name I have not heard in a long time. A long time.

Hence why you end up with 300MB x platforms, and tricks like upx.

In Java libraries are shared precompiled so the package manager either needs to be platform aware or distribute fat bundles.

Only for those that are yet to learn how to use jlinker.

Libraries like JCEF have support tools to download the libraries either at runtime or during the build, to offload from Maven Central.