You could base all the images on the same layer, then the disk space wouldn't be an issue, right?

It is an advantage in specific situations when you can't rebuild every container or you want to try to selectively update containers without rebuilding them. You should try to update the running containers as a rule but having options is helpful from time to time. In a properly managed container infrastructure it should be faster to update the container image reference before resorting to tactics like this.

It would be interesting to consider what it'd be like to swap out layers directly, instead of having to "rebuild" the final image.

Perhaps a hack for a free weekend.

That would lead to a small image size because you would just apply the .jar to a base Java install but it doesn't do anything for the container size because they all will have their own JVM copy.

I don't understand what you mean for the container size. If they share the same base layer it won't use more disk space to store than splitting it up, surely.

You're missing the fact that if they're all using the same layer (base image) for the JVM all the images will be deduplicated (well, CoW) so you could have a hundred different apps and they would only use the equivalent of a single image for the JVM (in terms of storage).