More specifically, you currently can't run untrusted code as root in a linux namespace, which is the default backend for Docker. There is work underway to improve the situation in 3 ways:
1) in Docker, to support backends other than lxc, including vm-mapping and openvz which have a better security track record.
2) In Linux, to further harden linux namespaces upstream so that they can safely be used to execute untrusted code as root [1]
3) in ops best practices, to combine linux namespaces with additional security measures (selinux, apparmor, clustering to deploy mutually untrusted containers on different docker hosts, etc).
[1] a big focus of the namespacing effort us user namespaces which makes a container "think" it runs as root when in fact it doesn't. User namespaces work great but haven't been around long enough to be vetted. Beyond that, namespaces are pretty robust and feature-complete already. What's left is to go through the process of auditing, testing and generally allowing it to stand the test of time and scrutiny. Eventually ops and security engineers will warm up to it and it will graduate to "production-ready", the way Zones, Jails and OpenVZ did before it. It's only a matter of time.
That being said, we are definitely making a long term bet on Docker and containers, and are confident security will improve over time.