The default email system doesn’t require any existing email infrastructure and is useful for testing as the email is sent from the server Strapi is running on. In a production like configuration you should/would have an actual email implementation along with all of the required DNS records (MX, DKIM, ect). Strapi itself cannot predict these settings in advanced and requires the user to configure them.
Strapi itself is not in the “email business” so to speak, hence why we have a handful of providers, actual implementation should be up to the user and we should only provide a viable test option (that being said most consumer ISPs block outbound port 25, hence why we have added an option in the CLI to reset passwords).
If you are willing to work on a better solution we would be open to seeing what you think, but please do open an RFC: GitHub - strapi/rfcs: RFCs for Strapi future changes before you open a pull request.