Docker's not production ready. The APIs aren't locked down and the developers haven't said it is production ready yet. It may be possible to break out of the container (if you expect to use it like a VM) and people are still fighting over if you should "Dockerize" at the application, service or executable level.
A more useful-and-objective piece of information, I think, would be the average/maximum number-of-nines of reliablity reported by current users of the project. Then you could just look at your own project's current reliability, and allow yourself to depend on anything more reliable than you are.
They are probably correct-enough in that you shouldn't be using Docker in production at Google/Amazon/Facebook/wherever. It's not yet nine-nines reliable. But Docker is probably more reliable than your startup's MVP, and you shouldn't let "not production-ready" scare you away from developing and shipping your new project using Docker.
Docker is a container, and I therefore apply the same set of standards that my linux distribution/kernel should fullfill.
What's the difference, exactly? In either case, a failure in the code composing the third-party component can, at worst, cause an instance of your application to crash and corrupt state, preventing instances on that machine from coming back up.
But as long as you've got immutable deployments[1] set up, when all else fails, you can just destroy the server (hosting the containers) hosting your app instances, and deploy it afresh, which should be automated to the point that it only takes a few minutes.
[1] http://chadfowler.com/blog/2013/06/23/immutable-deployments/
I don't see anything unreasonable about waiting to use a package until the devs themselves say it's "production ready".