Giving an application/user and entire trimmed down OS namespace reduces damage done from getting pwned significantly. Why use a system that protects processes from running alongside each other when I can just give them their own, fenced-in home?
Containers still use the same kernel, have access to the same filesystems (in practice), same devices, same ioctls, etc. There can be a lot more separation done in the future, but right now, you definitely gain a lot by isolating your containers using selinux.
Even with virtual machines, you want any breakout / external write vulnerability to be contained. That's why libvirt/kvm relies on selinux (or apparmor) for system protection and for cross-vm protection (https://libvirt.org/drvqemu.html#securityselinux)
It's naive to dismiss something because it doesn't meet the goal of "100%" secure. In practice it gets you very close and takes almost no effort, no maintenance, no headache. Historically that kind of thing will win in the long run.
But it doesn't mean "SELinux is not worth saving". Some kind of LSM (selinux/apparmor) is still a great safety net and protects us from an issue that VMs actually introduce. Once you break out of your VM, you have access not to a single host, but to a number of them in a way that no in-VM protection can stop or even detect. That's the reason we really need LSM protection. Not necessarily selinux, but something needs to be there.
The fact that the process, by default, runs as root and PID 1 within the docker container still has be going "You gotta be fucking kidding me?!"
I realize Docker has come a long way since the days of it being LXC based. Cgroups and several other safeguards have done a lot of docker security, and containers are much more lightweight than full VMs, but I'm still a little on edge about the security aspect.
Hopefully more people are becoming aware of the actual default behaviour.
Also moving data across VM/container boundary all the time is not a fun. Been there, done that even in lighter manner (with separation of system accounts for different activities).
As long as you establish some read-write and read-only shares between vms/containers, there should be no problem with moving the data. As in, you don't have to move it in the first place, but you need to design it the right way.