You start with the assumption of "properly set up container". Also I believe you are oversimplifying the attack surface.
A container escape can be caused by combinations of breakdowns in several layers:
- Kernel implementation - aka, a bug. It's rare, but it happens
- Kernel compile time options selected - This has become more rare, but it can happen
- Host OS misconfiguration - Can be a contributing factor to enabling escapes
- Container runtime vulnerability - A vulnerability in the runtime itself
- Container runtime misconfiguration - Was the runtime configured properly?
- Individual container runtime misconfiguration - Was the individual container configured to run securely?
- Individual Container build - what's in the container, and can be leveraged to attack the host
- Running container attack surface - What's the running container's attack surface
The last two are included to be complete, but in the case of the original article running untrusted python code makes them irrelevant in this circumstance.
My point you must consider the system as a whole to consider its overall attack surface and risk of compromise. There is a lot more that can go wrong to enable a container escape than you implied.
There are some people who are knowledgeable enough to ensure their containers are hardened at every level of the attack surface. Even then, how many are diligent enough to ensure that attention to detail every time? how many automate their configurations?
Most default configurations are not hardened as a compromise to enable usability. Most people who build containers do not consider hardening every possible attack surface. Many don't even know the basics. Most companies don't do a good job hardening their shared container environments - often as a compromise to be "faster".
So yeah, a properly set up container is hard to escape.
Not all containers are set up properly - I'd argue most are not.