Because it's not about some code or about some shared stuff. It's about atomic operations across different hosts without involving hard-barriered teams.
A container image can be seen the same way a machine image can be used: you ship an image of a solution instead of some files and instructions and 'hope for the best'.
If you imagine your application and it's required environment as a complete machine as a starting point, and then running/scaling that by simply having the only requirement on any host be "it must be able to run this image". That's a much smaller and more standard interface than individual files.
If you were to just make a 'smaller' version of that you'd end up with chroot/jails and if you want to use cgroups on linux for isolation you'd end up with containers (i.e. Docker containers). It's not the only method or the best method, but it's the easiest and most widely supported method.
Going even 'smaller' you could simply build static binaries with everything included and tell the OS that when it gets started it should do so with no permissions to access anything else on the host.
Smaller beyond that is unikernels where your application is the OS and runs bare on a host (be it bare metal or virtual).
The downside of the last two is that all the 'extra' files like assets and temporary data needs to be embedded inside that single file. The downside of chroot and jail are that there is no cross-host packaging method and it usually just works on one specific OS or host.
Virtual machine images and container images have the same benefits but the virtual machine has the drawback that it is much bigger, much slower to start up (generally) and has a much larger attack surface and maintenance overhead.
What containers aren't is:
- A package manager
- Application Server Containers
- Configuration management (well it shouldn't)
- A replacement for a single-purpose VM
Technically containers also require you to be stateless and read-only. This nearly universally leads to better applications, better operations and better security. That gets us to the cattle vs. pets part of containers: the idea is that you ship containers, not whatever happens to be "inside" those containers. As long as a container is "good", any host that can run containers should be able to perform exactly the same to the point where running it on your laptop, on a mainframe and on a standard bare metal server does exactly the same thing. If you then wipe the server, install a different OS that can run containers and start the container again, it still does exactly what it should do.