Hi all, @akbooer asked me to join this community - so far I was only active on MCV. I am the author of the Docker image for openluup that is referred to in this thread.
I quickly read the complete thread. Most of the comments contain valid statements.
Personally I would not avoid containers as the pest - in fact, you can't ;). Containers exist for a long long time (at least in the Linux kernel) and play an important role for isolation of processes/networks/filesystems. Docker has made this system significantly easier to use and understand. By now also Windows supports containers and (in the latest builds even without HyperV virtualization) can even run Linux containers. This begins to fade the most significant difference between VMs and containers away, this being virtualization (for VMs) versus isolation (containers). Opposed to VMs, containers are very lightweight (try creating a VM that runs openLuup in under 7MB :D). A container does not contain a kernel and does not have an operating system. It also cannot run on itself.
Maybe some of you experienced the 'dll hell' - the issue where the installation of an application breaks another application, because one overwrites a shared library of the other. This is what you can prevent by packaging applications and one of the reasons for things like snap, flatpack and docker to emerge.
So as @toggledbits mentioned, a (well written) container indeed does not contain much. A docker container basically provides the 'batteries included' concept. This makes it very easy to get started with a new application like openLuup. In order to get the same experience with a VM, you'd need a pre-build image, or an automation system like Ansible, Puppet or Chef - tools that not every newbee is likely to master.
There is no general 'better' when it comes to VMs verses contains and in many cases both are used, each for their own specific benefits, one of which is personal preference.
When you, like @akbooer, want to consolidate your setup on a not highly powerfull NAS, a container is the way to go.
).