"Docker" isn't at fault here either way, as Docker isn't its own "execution driver" (in Docker parlance) any more; that would be https://github.com/opencontainers/runc.
But to answer the spirit your question, each container runtime uses its own peculiar combination of such constructs. It's helpful to know that this attack allows you to break out of the combination used specifically by runc, and thereby to break out of any system relying on Docker (with the default runc execution driver.)
I doubt any runtime would have prevented this bug; some have seccomp-bpf profiles to blacklist some kernel operations, but I doubt any block a function as basic as waitid().
But to answer the spirit your question, each container runtime uses its own peculiar combination of such constructs. It's helpful to know that this attack allows you to break out of the combination used specifically by runc, and thereby to break out of any system relying on Docker (with the default runc execution driver.)