A valid question— certainly there's a school of thought that says one process per container, end of story.

However, there are lots of applications out there (especially legacy ones, think stuff like Zoneminder) which are made up of multiple small daemon-type processes sharing state across ports and maybe even the filesystem, and have a strong reliance on system services like cron or log rotation. Yes, with effort an application like this could be be fully "ported" to a container-native setup, but the path of least resistance is often to just make the container environment present as being more like a full VM.

I get the impression a lot of the entire point of containers in those things is to deal with those awful zoneminder style designs, PHP junk that needs specific Apache configs, etc.

I prefer to just avoid any application that requires a service to in any way be configured to account for the app.

It's bad enough that Zigbee2MQTT is a separate process, but it's acceptable because it is a pure layering model and as long as you are local only and not needing passwords, there's no manual config.

Things like ZM that need an actual database are just insane. Multi-page configuration instructions for something that the(Sadly closed source) AgentDVR does with one process, no containers, no major configuration to conflict with anything else.

But modular apps exist, so we need containers to make them act like monoliths.