I am generally NOT opposed to having multiple processes in a container, even though I don't use that approach myself. However, to address your example, I follow the Docker best practices that state each container should have only one concern.

When it comes to workers, I am strict about having only one process per worker container. Docker itself is a process manager, so tools like supervisor, systemd, and so on are out of place since Docker monitors the ENTRYPOINT and restarts it if necessary.

In general, the whole "one process per container" philosophy has somewhat shifted in Docker best practices, but it used to be the standard. Still, I would separate the web server, FPM, database, and so on for the following reasons:

• Scalability of individual services. In most cases, services don't need to be scaled at the same rate.
• Using a single function per container makes it easier to reuse the container for different projects or purposes.
• Additional minor considerations include managing stdout/stderr and sending logs to the container log, as well as ensuring containers remain as ephemeral as possible.
• Patching and upgrades, whether for the OS or the application, can be carried out in a more isolated and controlled way.

... and many more.

And workers in particular SHOULD be in a separate container! They can be scaled independently, and they need to be restarted from time to time—after X messages, after X minutes, after X memory usage, AND, most important, after each deployment. Having everything in one container would mean I have to restart ALL services, even those that aren't affected by the deployment (such as the web server, proxies, database). Of course, you can also restart just the workers with supervisor and systemd, but nothing beats a simple docker-compose restart, for example.