The approach you are suggesting is a valid one, and there are certainly some people that do that.
The perceived overhead of running multiple containers is greatly reduced once you introduce the docker-compose tool. The docker-compose.yml can be considered the black box you are looking for. Any application can be started with docker-compose up -d, and all containers will come up in tandem.
Having separate containers allows you to create a separation of concerns between the different services in each of your applications. That way, if I need to change something about the database, I’m not also changing something about my web application server in the process.
You’ve already pointed out what in my opinion is the biggest issue, and that is the added difficulty of adding redundancy. I may very well need to add additional capacity at some point. Adding more application server instances can make this possible. If those application server instances come with a database that they are hardcoded to, this is more difficult, and things must be rearchitected.
Much of what is considered best practice in the docker community comes from concepts laid out in the Twelve Factor App: http://12factor.net/. Since a container is a way to run a process, each container is in charge of one process. Multiple instances of that type of process will result in multiple instances of that container. Different types of processes will necessitate multiple types of containers, or different images.
At the end of the day, I would suggest you build a test application and try both ways of deploying it. Which one suits your specific use case better? Will you never ever need scaling? Does combining multiple services into one container actually simplify the deployment for your specific requirements?
/Jeff