It mostly isn't. Almost all Linux container escapes only require the ability to make system calls to the shared kernel from processes inside the container. The system container doesn't really restrict this ability. It also increases surface area to compromise the container before attacking the host system, since there's now a bunch of extra software running inside the container.
If privilege isolation is a priority but you want to use containers, gVisor and Firecracker are way ahead of anything else. The Linux kernel API has proved to be very hard to secure, and not for lack of trying.
"Systems containers" are almost certainly isn't more secure since 'root' means things, even in a container.
Containers just leverage existing Linux namespace isolation techniques to isolate applications.
A good way to think about it is that they act like blinders on a horse. If applications can't "see stuff" or reference items outside of the container then they don't know it exists and don't know how to interact with it.
"application containers" can take advantage of more then just namespaces to isolate applications, such as running them as unprivileged users inside the container's context and thus limiting them from the sort of kernel features that get exposed inside the containers. Or cgroups to limit resource usage and other smaller things like that.
Regardless "Security" and "Containers" really shouldn't be written about in the same paragraph without MAC framework like SELinux in place or additional isolation techniques like VMs.
Although VMs are a lot more like containers then people realize.
Any shared resource between containers or the kernel itself is an attack surface.
Both options have a very wide attack surface - the kernel api.
Nothing really beats virtualization in security, the surface shrinks to pretty much just the virtualization bits in the kernel and some user space bits in the VMM.
Complexity is generally the enemy of security, because securing a system requires understanding it. If you can build a more understandable, less moving parts, more observable, more easily manageable etc system with system containers, it's a security argument.
The article is pretty useless at explaining the difference, I agree. It makes claims about Docker that aren't true (e.g. single container) while making inadequate reference to the OS features likely involved in making "system containers" what they are (SECCOMP, capabilities, network namespaces, nftables).
As an engineer this page has a real "trust me bro" feel to it. Maybe fine as a marketing and product positioning thing, but not interesting for HN.
This has been one personal pet peeve with the documentation surrounding Incus.
As a stack, Incus has been exceptional, it has largely replaced Proxmox and Podman Quadlets for me. For context, I homelab so I cannot generalize my claim to SMB or enterprise.
But the documentation has been very end user oriented, information regarding specifics like seccomp as you mentioned are only discoverable with the search bar and that leads to various disparate locations; and that also isn't taking into account that some of the more nitty gritty information isn't on the Incus portion of linuxcontainers.org, see the LXC Security page for example: https://linuxcontainers.org/lxc/security/
