That is not a good argument and it shows a basic misunderstanding of what containers are and how they should be used. Containers are NOT virtual machines.
A container runs a (short lived) process. Think executable, like
top, or a shell or Python script. When the process ends, the container is destroyed. The process is isolated from other processes running on the same machine. Basically the kernel reserves some space (memory/CPU) for that process, runs the executable inside that isolated space, then releases the reservation. The reserved space is the container.
A virtual machine on the other hand is an emulator. It pretends there is an entire computer and it needs an operating system to, well, operate it. It boots a kernel, starts an init system and then a whole bunch of processes to deal with every aspect of the emulated hardware.
A container is supposed to be small and fast. And it's not generally supposed to run for days, or even hours. Compared to a virtual machine, which gives the user more freedom, but also takes more resources. Packing an entire distribution like Debian or RedHat inside a container would defeat the purpose.
For example, you're not supposed to run a web server (say, Nginx + PHP) inside a container. When a page is requested, you run the PHP script inside a container to generate the page, hand the output over to Nginx running outside, then the container is destroyed. If you want Nginx+PHP in the same space, you're better off with a virtual machine. There may be reasons to set it up as a container, but technically speaking Nginx workers already do the work of containers, so you'd just be duplicating that.