I would think that if you're already going to do the SMTP transaction, the average (plaintext) email message body is small enough to slide into the same packet as the end of the transaction headers. It's the same as keeping the data of small files inside their directory-entry structures on disk.
On the other hand, it would indeed be interesting if email was simply a "unicast presence notification" channel to allow accounts to publish knowledge of a (private, ephemeral, encrypted, authenticated) message channel to other accounts, and then messages flowed via automated subscription-based pull. You'd still want your MUA to be a web service with active background polling, though (like cloud RSS reader services), since otherwise a user could send a message and then "retract" it from their feed before your own client had retrieved it.
But this would solve at the very least the spam problem: you could simply unfollow a channel that's sending you email, and receive no future messages on it. It'd be like every (sender, receiver) pair having its own dedicated inbox, that the true receiver consumes only voluntarily.
