The recommendation comes from the goal and design of the Operating-system-level virtualization
Containers have been designed to isolate a process for others by giving it its own userspace and filesystem.
This is the logical evolution of
chroot which was providing an isolated filesystem, the next step was isolating processes from the others to avoid memory overwrites and allowing to use the same resource (I.e TCP port 8080 for example) from multiple processes without conflicts.
The main interest in a container it to package the needed library for the process without worrying about version conflicts.
If you run multiples processes needing two versions of the same library in the same userspace and filesystem, you'd had to tweak at least LDPATH for each process so the proper library is found first, and some libraries can't be tweaked this way, because their path is hard coded in the executable at compilation time, see this SO question for more details.
At the network level you'll have to configure each process to avoid using the same ports.
Running multiple processes in the same container require some heavy tweaking and at the end of the day defeat the purpose of isolation, if you are ok to run multiples processes within the same userspace, sharing the same filesytem and network resources, then why not running them on the host itself ?
Here is the non exhaustive list of the heavy tweaking/pitfalls I can think of:
Handling the logs
Either being with a mounted volume or interleaved on stdout this bring some management. If using a mounted volume your container should have it's own "place" on host or two same containers will fight for the same resource. When interleaving on stdout to take advantage of
docker logs it can become a nightmare for analysis if the sources can't be identified easily.
Beware of zombie processes
If one of your process in a container crash, supervisord may not be able to clean up the childs in a zombie state, and the host init will never inherit them. Once you exhausted the number of available pids (2^22 so roughly 4 millions) a bunch of things will fail.
Separation of concerns
If you run two separated things, like an apache server and logstash within the same container, that may ease the log handling, but you have to shutdown apache to update logstash. (In reality, you should use the logging driver of Docker)
Will it be a graceful stop waiting the current sessions to end or not ? If it's a graceful stop, it may take sometime and become long to roll the new version. If you do a kill, you'll impact users for a log shipper and that should be avoided IMHO.
Finally when you have multiple processes you're reproducing an OS, and in this case using a hardware virtualization sounds more in line with this need.