Your average OS kernel has an abundance of interfaces, all of which may have bugs enabling a malicious program to elevate its privileges. The OS<->hypervisor channel can be much more restricted.
With containers, programs in the container are generally talking directly to the host kernel through the same interfaces as any other program, so you don't get that benefit.
In my experience, the vulnerabilities in the different layers tend to to be cumulative rather than restrictive, due to the fact that the stuff you want to protect is in the vulnerable layer.
However, all code has bugs (including security-critical ones). Minimising the attack surface of trusted elements is an important part of defense-in-depth.
Xen is <150000 LoC, and a lot of that can be run in less-trusted stub domains. The linux kernel runs in the millions of lines (admittedly probably not all compiled-in, but it's still at least an order of magnitude more), and none of it can be fenced away from the sensitive bits.
I'm not saying containers don't have their place. But there are benefits to full VMs in security critical infrastructure.
When comparing the security of containers to VMs, vulnerabilities in the OS should be out of scope. A more realistic attack scenario would be a virtual host or container server with two VMs/containers: a trusted on and an untrusted one. Assume neither has networking, but the untrusted one is running compromised software. The question is how easy is it to escalate privileges from the untrusted container/VM to the trusted one?
I'd say that Xen's small code size and resulting easier auditing is a benefit here.
http://www.slideshare.net/xen_com_mgr/lfnw2014-advanced-secu...
The options are rebooting hardware/OS/compilers/apps (Mill Computing) or disaggregating existing operating systems as has been done by Xen and Hyper-V, using CPU features from AMD, Intel and now ARM.
Isolated hardware regions will become smaller:
http://theinvisiblethings.blogspot.com/2013/08/thoughts-on-i...
Namespaces/containers are for trusted workloads.
Granted. But unless their are glaring faults or unacceptable performance issues in the extra layer(s) you can gain some "security in depth" with each layer shielding the next and previous to an extent, reducing the potential fall-out of certain classes of bug.