Bundling the JRE in the bundle typically results in something that is not redistributable with the default OpenJDK license: The Java ecosystem is heavily tilted towards the Apache license, but Hotspot is licensed under the GPL v2 only (no classpath exception). The Apache license and older GPL versions (before 3) are generally assumed to be incompatible.
Every modern openjdk build is licensed as GPLv2 + classpath exception. That exception includes hotspot, since it's part of the jvm. That exemption allows shipping the JVM with your app or linking to it. Otherwise a bunch of enterprise software couldn't exist.
You're asking about a fundamentally different thing.
An app bundle (.app, .rpm, .deb, .msi/.exe etc.) are things jpackage can build for you and are a single shippable artifact for a user with a JRE included so they don't need to do that. It's designed to make it easy to ship Java applications around.
I'm not asking about a fundamentally different thing. The success of other languages isn't because they produce installers. Have you tried native image for a non-trivial application? I've been using it since it came out; I was the first adopter of native-image for Quarkus on Windows. I even wrote the documentation for it at the time. It is not trivial to use, the compile times are extremely long, and the resources it requires are sometimes more than a developers machine can provide.
Or use a graal to build a native-image and ship that around.
But that's not what people want. They want an .exe or a .app, or .rpm, or whatever. That's a container for holding that .jar and it is platform specific and there is no workaround to that problem.
It does all of this work for you and its a standard tool that dumps out a platform specific application bundle.
The only people living in 2010 are the ones that choose to live there with incredibly outdated takes on things they dont understand.