I've thought about this, too. Certainly much communication on the modern internet is realtime, so arguably a protocol based on realtime communication makes more sense than a protocol conceived for asynchronous communication. A system that allows a conversation to move between the two seems ideal -- look at how Facebook collapsed the distinction between IMs and "messages". Trying to have a realtime conversation over email (even with a thread-aware, modern client like Gmail) is still an exercise in frustration.

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.