One of the most important features in TeaVM is its inteprocedural dead code elimination algorithm, which allows to produce very small code for simple Java programs. For example, Hello World produces about 40 kb JavaScript, TodoMVC (http://teavm.org/live-examples/todomvc/#/) is only 125 kb.

If you look at how much their demos in their gallery downloads, it's in the hundreds of kilobytes on average. Granted these are not full web apps but even still it's roughly on par with the latest web app framework's demos.

Performance is not too shabby either

If you are compiling to the JVM the output is probably nothing related to a web app.

One isn't compiling to the JVM with this, they're compiling to WebAssembly. And I think the point of this is to compile JVM code to WebAssembly, right? Am I missing something even larger than that?!

Should someone want another VM to run their code in; how, good is this at reducing the size of the std lib or the JVM itself? Can I depend on useful packages with this, or will they immediately shit the bed? Will the payload be something like 150mb?

In that case it will be interesting to observe this in practice. My fear (and prediction) is a lot of continued frustration and failure because the web environment is a different context than the JVM target with many different technical requirements. If the underlying technical differences in the environments were so trivial in the first place then simply swapping languages from Java to JavaScript wouldn't be so challenging.

Generally speaking, there are ways to reduce a JVM library to the subset that is actually ever referenced by the app during compilation, like ProGuard. So of the 150 MB theorized library payload only maybe a megabyte is actually used by some app and needs to be delivered to client (browser).