It sounds like you have the right intuition. A lot of the time when beginners are starting out they will try and put their entire application stack (say Postgres/Elasticsearch/their app/etc) all on the same container. This is not great because it is impossible to scale these services independently when configured like this.
I think advocating "process-per-container" was a poor choice, when really "role-per-container" was what the intention was (imo). You may have a separate container for Postgres, Elasticsearch, and then your app. But if every now and then your app needs to spawn a child process to do some sub-task related to the app, that's fine too.
It really depends on what the multiple processes are, so you should ask yourself "is this a logically separate job that I would want to scale and manage the lifecycle of independently from the main app?" and that'll help you make the best decision.
I think advocating "process-per-container" was a poor choice, when really "role-per-container" was what the intention was (imo). You may have a separate container for Postgres, Elasticsearch, and then your app. But if every now and then your app needs to spawn a child process to do some sub-task related to the app, that's fine too.
It really depends on what the multiple processes are, so you should ask yourself "is this a logically separate job that I would want to scale and manage the lifecycle of independently from the main app?" and that'll help you make the best decision.