tl;dr Docker != runc. runc has only had one known partial container breakout that required host coordination, and all of the runc CVEs are useless in rootless containers (which is what jessfraz is using).
Of the vulnerabilities you've listed (while searching "docker") only four were actually runc vulnerabilities, and most required you to be running root inside the container (or required you to have some form of privileged access on the host). Also, runc doesn't use chroot -- we use pivot_root.
You've also just done a full-text search for "docker" and several of the CVEs just have the word and are not actually vulnerabilities in "docker" nor runc. I don't understand what this is meant to show.
In particular, these are the only vulnerabilities in that list that are arguably related to your point.
* CVE-2017-16539 -- a default configuration error allowing a DoS if you're root in a non-user-namespaced container. The PoC in TFA uses user namespaces and thus this attack is pointless. Not to mention you shouldn't run as root anyway, please stop doing that.
* CVE-2016-9962 -- a partial container escape if you have another process joining the container, there were also several kernel bugs found as well as a result. Also requires root, and user namespaces had a fix for this in the next kernel version. Again, stop running stuff as root.
* CVE-2015-3627 -- an information disclosure that requires a malicious rootfs (so you have to have host-side coordination to set up the rootfs before the container starts), and was never present in "runc" just the library that predated it.
* CVE-2015-3629 -- a partial container escape that required significant host-side coordination (you have to change the configuration of the container to be malicious). Also wasn't present in "runc" just the library that predated it.
So, there has only ever been one plausible container breakout in runc to-date and it was CVE-2016-9962 (and it still required using bad practices). You could argue that CVE-2016-3697 was also a runc bug, but that code was only used by Docker at the time (more of a library bug than a container breakout bug). CVE-2015-3629 requires you to effectively create the container that you're going to break out of, so not viable from a "bad code in a container" perspective.
I'm not excusing these bugs, but they should be put in context. CVEs have CVSS scores for a reason -- they are not all created equal and you need to look at each one individually before coming to conclusions.
I do respect the folks who work on Xen, don't get me wrong, but I don't understand this argument for the security of Xen. If I only consider the 11-year-old floppy privilege escalation[1], then runc is already on better footing in terms of "which project had a worse example of a vulnerability resulting in containment escape". Whether this is due to the young age of containers on Linux, or because containers levarage many different security features, I'm not sure.
Source: I'm a maintainer of runc, and I found CVE-2016-9962.
[1]: https://xenbits.xen.org/xsa/advisory-133.html