Let's use heartbleed as an example. It is easily possible with Guix to walk the dependency graph for any package or system configuration (container or otherwise) and inspect for known vulnerable software. Docker simply does not, and cannot, know the level of detail that Guix knows about the composition of software and systems.
Furthermore, the Guix tools that build containers use a functional, declarative programming interface. Contrast this with Dockerfiles which are an imperative sequence of steps in which you mutate a disk image in a specific order. To utilize Docker's caching abilities, you have to very careful about the order in which the directives in the Dockerfile are evaluated. In Guix, the order doesn't matter and the "cache" (it's really memoization) can be effectively used when any component of the system has already been built before.
I've picked on Docker a lot here because it's the most popular, but you can substitute Docker for any other image-based container system and the same things will more-or-less apply. Docker is great for making things easier right now, in which the status quo package managers are weak and you need on average 3 to 4 package managers to deploy any given web application. But it's not the future. Docker is based on binaries whereas functional package/configuration management is based on source code. We can do much better (and we are doing it already) by building on the functional package management paradigm.
In the Windows world, it's common to have the libraries you need stored in ~/Program Files/Program_name/ . Now, each program dumps in its program home the library, only because it cannot guarantee the library would be in the system.
In Linux, we deal with having different major versions of said library. nd minor versions are clobbered by major. So when someone who wrote stuff using python 2.7.2 and 2.7.3(bugfixes) comes out, there is invariably something that is broken.
A container that encompasses "Python", and holds all the versions would be a great deal. Same with other programs. They could interact, but their install and environment would be encompassed as a complete "Python", regardless of version or bugfix.
Generally also containers are built on existing Linux distributions and use their packages. I still haven't figured out exactly what I want to do but my vague future plan involves containers bootstrapped from Nix expressions. That's just to get a level of indirection to abstract away NixOS so I can run app services on whatever distribution.