If you base your container on Debian/Ubuntu, that is. And is at odds with the principle of only packing what's actually needed. If you base all your images on Debian/Ubuntu anyway, then what's the point of containers? If there's a vulnerability, you'd have to upgrade all of them anyway and they're living now as binary images on your build host instead of a versioned O/S.
All containers give you a guaranteed build process and proof that mutable state is only stored in well-known locations. That’s a huge advantage over full servers right there as any experienced Unix admin will tell you.
If you’re using a container based on an OS, you are installing far, far less and having only one process running. That again is a huge savings: no time securing postfix and cron, etc.
Another big advantage is that you’re shifting this work from the deployment time to build time. You do it once and can test it as long as you want before deploying it to production - no more failures because Red Hat’s mirror is unavailable or malfunctioning during your prod update window.
A lot of this discussion seems to revolve around running java inside containers without explicitly saying so. Running the JVM brings along a whole host of dependencies which is typically resolved by running a full blown base OS image. It is still desirable by many teams due to past issues with maintaining the JVM on VM or metal hosts.
