I don't know about Chef because I have never used it. I use Ansible, which can be used for much of the same things.
Obviously Docker itself is for managing containers. The Chef-life capabilities are the building, repoing of images, and config files that you use with Docker.
Once a container is running, then Docker's job is to keep the thing up rather than making changes to the existing container. That's where something like Ansible might come in. Anything else you might want to automate after the container is already running could be handled by Ansible. For example, maybe you want to force a DB backup on all your X containers, then you could run an Ansible playbook to do that. There isn't anything in Docker which would allow for that.
I like the flexibility of Ansible as a general tool, so I prefer to keep my server setup recipes in Ansible. Even if I don't have to use those recipes often because I only need to setup one base image for each need, I still like to have that Ansible playbook. I haven't tried all the new features of Docker yet though. I had a back off a bit a few months ago because I couldn't keep up with all the changes.
I do agree that Docker makes Chef less appealing for automating deployment of applications that should be containerized -- most web apps, Redis, etc. However, Docker is not yet suitable for every workload. For example, if your application/service has complex storage or networking requirements, Docker may not be a good fit (yet).
[1] For my specific use cases.
