> This includes /proc-related escapes as well as more general VFS attacks.
Right, there are numerous ways to mess up a chroot, just like any other namespace isolation such as process and network namespaces.
Basically as soon as you bind one namespace inside another, the containing namespace will have access to the contained namespace. That much should (hopefully) be obvious. If you mount a procfs inside your application it is no longer contained from the syscalls that procfs necessitates.
But that's not typical for an application that drops privileges. Even decaces old software such as BIND, which has had numerous vulnerabilities over the years, chroots to the data directory and drops to an unprivileged user by default.
There is an important distinction here whether the application itself should drop any unnecessary privileges, as exemplified by chroot, seccomp and pledge, or whether the application should be started with as little privileges as possible, as exemplified by SELinux and Docker. In the former case, the responsibility falls on the application developer, and in the latter case on the system administrator or end user.
The article explicitly argues for SELinux instead of the chroot. That is, arguing the latter approach is superior to the former. That is experimentally verified bad advice by now.
Software such as Chrome rely on chroot-style compartmentalisation and is much better off because of it.
> tools should have switched to using pivot_root(2) a decade ago
Yet people keep using the simpler tool. The threat model is the same and pivot_root is easier to misuse. In fact, it is probably a good idea to do both.