This has been discussed before with regard to external links to images. I think that always made sense, but it makes even more sense to do this when the core content is external. Then fetching it would be just another part of the SMTP/HTTP transaction sequence to deliver a mail.
(Actually, thinking further it would have to be done server side to avoid leaking your personal IP. For a webmail provider that’s obviously straightforward, while IMAP servers could be extended to automatically replace AMP email directives with a static HTML attachment.)
The first stage of spam filtering, and greylisting, also reject at SMTP transmission time.
I'd do the HTTP fetch when SMTP is about to accept the message, making the HTTP round trip just another part of the transaction.
Since spam filtering is likely to look at the HTTP response, you might want to reject the SMTP transaction after seeing the HTTP response, rather than accept the SMTP transaction based on address alone.
"The AMP version of the message is embedded into the email as a new MIME part, in addition to the HTML and plaintext, ensuring compatibility across all mail clients"
From https://amp.dev/documentation/guides-and-tutorials/start/cre...
I mean, different mime versions of the same content are a possibility to do this transition: Send both plaintext, HTML and markdown, and the receiver could choose to display markdown if he otherwise would display plain text.
To be honest, this won't come. Google is pushing AMP into mails, that's exactly the opposite direction.