As a proof of concept. It should be easy to implement a "shortcut send" into an email client, which sends a mail directly over XMPP, if sender and recipient are both online with this client.
For a mature messaging protocol, that smells really really bad for any serious use.
(Genuinely curious - I see suggestions for replacing email on a regular basis, but rarely ones that are deeply thought out.)
One of big potential benefits I see is the XMPP concept of contact requests. Simply separating new senders from existing senders at an architectural level seems like a great start for an email replacement, both in terms of user experience ("who I know" is fundamentally separate from "who I don't know" regardless of the client), and in network utilization (spam is only ever as long as a request header instead of an entire message).
Because in the end, and despite all its kludges, e-mail doesn't need replacement. Its biggest problem remains spam, and even that is under control by all the major providers.
The core support for the concept of presence in XMPP is also pretty compelling -- especially in remote collaboration settings, where transparency around another person's comings and goings can significantly reduce conversation friction.
That being said, the current XMPP protocol, even including the large set of approved protocol extensions, still falls very short of what would be needed for it to serve as a viable email replacement. As others in this thread have mentioned, the core protocol doesn't include any specification for how to handle messages directed to offline users, and while XEPs have been developed to address this, implementations still vary widely between implementations. Limited by the structure of JIDs, the protocol extension for multi-user chat ends up being a clumsy hack. It looks like there are also problems with large binary data transfer (see http://metajack.im/2008/06/10/binary-data-is-xmpps-achilles-...).
Obviously, a lot of these problems can be resolved with additional protocol extensions, but this risks creating a hodgepodge of conflicting standards and generating a menagerie of different implementations before drafts are settled on. The fact that the core XMPP RFC makes no allowance for offline messages, which is essentially the core of email, makes me think it might be unwise to try to hot-swap the two.