runC creates Linux containers. Containers and VMs are not security solutions, rather system administration and provisioning solutions.
chroot() was originally implemented as a type of container. It allowed you to run programs (especially before the adoption of dynamic linking) from a private directory tree when building, installing, and testing software, without risking overwriting the real system. Basically, it's purpose was just like Docker.
But the use of chroot() as a security solution is different. You don't usually mount /dev or /proc in a chroot jail as that would defeat the purpose. The purpose is reducing the code surface of kernel and other privileged code available to software that might be abused to tickle bugs and elevate privileges.
Containers don't reduce code surface area at all, not to the kernel, nor usually to stock SUID and SGID binaries. All the same devices files _and_ system calls are still available, as well as typical SUID account and system management binaries. It might have security related benefits in the sense that you can, e.g., remove application-specific SUID binaries from some containers but not others. But that's no different than chroot, and so it's not really an improvement over chroot in that sense. More importantly, the code implementing Linux containers is complex and has opened up far more kernel bugs than it's closed. There are good reasons why most kernel developers, including even Linus for long time, resisted attempts to expand the chroot namespace model. In terms of security you'd be better off recompiling your Linux kernel without all the container namespace code.
VMs seem better security-wise until you realize a VM's interface to the host kernel is through device drivers. And the device driver model of monolithic Unix kernels is a security nightmare. Ironically, it wasn't until VMs came out that hackers had such easy and broad access to manipulating device driver code on the host. Unix's "everything is a file" approach always limited that ability. Where that approach broke down, like with ioctl, was always a hotbed of exploits.
Blackhats haven't had much trouble taking control of host kernels from guest VMs, although because that path is less well-trodden it's not something script kiddies are typically capable of. As VMs get simpler and move away from hardware and driver emulation, the security benefit of VMs will improve. But their utility as sandboxes for code you don't control will also be diminished. In many circumstances seccomp and pledge will remain the better option, especially from a developer's standpoint.
Note that SELinux doesn't limit access to system calls, and only indirectly limits code surface by making it easier to restrict access to logical resource objects. SELinux wouldn't have prevented or hindered in any way the recent recvmmsg() remote root exploit Linux. It's function is quite different than pledge and seccomp. SELinux can be used in tandem with seccomp. But given the real-world threat model out there, if you were to only rely on one, then seccomp is far more valuable, IMO.