For the client2server connection TLS certificate is needed to make sure user credentials cannot be sniffed out. It is nearly trivial to setup a fake Wi-Fi access point with the same name and password and MITM connections there. Once you have login and password of the mailbox, you can monitor when user receives messages persistently even after the user has switched to another network. This could be mitigated with some cryptography e.g. by using SCRAM authentication like most XMPP server do (as long as user connection is not MITMed during the “registration”), or by using OPAQUE which is not standardized or implemented by anyone for email, but we are not there yet.
I don’t get this, you only need a domain name to get a certificate, and your domain name is already known.
Certificates are free, you don’t need to buy one.
Depending on certificate renewal is indeed a problem, e.g. during internet shutdowns they cannot be renewed. For client2server there is a work in progress to keep the server usable even if certificate expires: feat: allow TLS connections with invalid certificate if the key is unchanged by link2xt · Pull Request #8086 · chatmail/core · GitHub
For server2server connections using not self-signed certificate is probably less important than for client2server connections, but you can still at least detect MITM if you use CAA records or monitor certificate transparency logs. We are anyway moving the code for connection between chatmail relays into Rust, so may eventually move similar logic that will allow using expired certificates: feat(transport): Remote delivery over SMTP by j-g00da · Pull Request #104 · chatmail/filtermail · GitHub Currently chatmail relays lose federation when certificates expire.