> you are leaving out the separate kernel running in the VM, it can have it's own vulnerabilities.
However this kernel is contained by VM and a bug there should not harm other VMs which is not the case with containers. Plus with the Qubes design an infected VM cannot have a permanent rootkit installed as a VM reboot brings clean kernel image and the root filessytem.
> making such a selection is very hard, and is very likely to change over time as apps grow new features.
This applies IMO to the containers as well as there one has to define new rules for evolving applications to allow them to inteact with each other.
> that there is not 'one true answer',
That is very true. However, within the given constrains one approach at a particular moment can win.
For example, one a relatively resource constrained system without IO and harware virualization features containers are a clear win especially if one has option to define the application API from scratch and apps and libraries are typically written in a type-safe language. Android is a good example of that. It also demonstrates how sound container-based foundation allows to adapt the system to new harware with minimal efforts.
On the other hand if the goal is to run the current native desktop applications that need to iteract with each other using the established API and that run on standard hardware, then VM and app domains are the winner IMO at this moment.