Also an “encrypted email host” needs to process the metadata in order to deliver the mail. For mail that needs to be sent to a different server, the receipient’s mail address needs to be decrypted in any case. Even for mail that has a local receipient there is as far as I know (beware: not an expert) no server software that can do this without decrypting the metadata first.

The connection between the sender/receipient and their respective mail server is encrypted (with any decent mail hoster, at least - and both users can check the encryption in their mail client), so the metadata isn’t publicly readable during this connection.

Server-to-server communication is a different story though… This could in theory be unencrypted (it almost always is encrypted though), and as a user one needs to trust one’s mail hoster and the mail hoster of the receipient that they support encryption for server-to-server messages…

Still, I don’t think there is much to gain by adding yet another layer of encryption to the metadata. In the end it’s just going to be encrypted metadata in an encrypted connection, where the same parties have decryption keys for both, the metadata encryption and the encrypted connection…

With an encrypted message body it’s different, as that’s irrelevant for the delivery of the mail, and therefore no mail hoster needs to be able to decrypt it.