After I wrote this, I see that the OP has a usecase where they've got a shrunk to fit AWS instance. So this is more useful than I thought, but I still don't think that's a huge audience. (The OP himself just upgraded the instance, after all.)
Barry Warsaw writes:
I can imagine different ways of doing it. For example, systemd socket activation on OSes that support that for the REST and LMTP servers. And maybe use inotify in the master watcher to spawn queue processing runners on demand. These would all be interesting things to explore, although they may not be universally appropriate (i.e. not all *nix systems supported by Mailman run systemd, nor support inotify).
Not to mention that spawning is typically a heavyweight action, so if you're heavily loaded enough to care about load, you'd need to add complex logic like that used by Apache to ensure you have same processes/threads hanging around to answer frequent calls, rather than one-shot "CGI" style. We do have thread and process pools in Python, but they wouldn't necessarily be compatible with this use case combined with systemd or inotify without additional logic in Mailman.
If somebody wants to mess with this specifically, it could be useful. But I think it's kind of a long shot given the kinds of scenarios Mailman is typically used in (lightweight Mom & Pop shops, virtual servers with Mailman-as-a-Service, and hard-core 5,000-list 100,000 message per day university settings be the not unusual extremes). Sort of like gilectomy efforts in Python itself (maybe //arry would like to work on this? ;-) ;-) nudge nudge say-no-more, eh?)