To add some context, we had intended to split up mailman-core and mailman-web on separate machines. With such a configuration mailman-core should definitely listen on the public IP or 0.0.0.0.
At the same time, this configuration is a standard way to provision servers "in general":
/etc/hosts:
127.0.1.1 server1.example.com server1
There are multiple articles about the topic if you google "127.0.1.1". This technique allows a server's name to always be resolvable locally, it's always correct and doesn't need to be updated if the external IP address changes, it is robust to complexities about NAT or proxies. This allows an application on server to resolve its own hostname consistently. At the same time, a remote client would use traditional DNS, discover an IP (not "127.0.1.1"), and connect to the server remotely. Otherwise, every time the server's IP changes, you need take the extra step of modifying /etc/hosts. With server automation you'd need to discover the correct IP first.
So, adding a "listen" or "bind_to" field is a "bug report/request for enhancement". It would be helpful in allowing mailman-core and mailman-web to run on separate machines.
However our latest plan as of this moment is to revert back to a one-server implementation. mailman-core and mailman-web will be on the same machine. Thus, the enhancement is not critical. It still seems "theoretically" useful to implement the fix, unless the documentation states "it is recommended that core and web should be on the same machine" or similar.