As a user of a web browser--an abstraction over HTTP messages--you don't care about each individual HTTP response; you only care about pages. Sometimes an HTTP response will deliver you new pages; sometimes it will modify a page already loaded. Web browsers only still really use HTTP at all because the verb set (GET, PUT, POST, etc.) so closely aligns with the things people want to do on the web. It's an excellent protocol for generic RPC between machines, that also happens to be usable directly by humans to GET web-pages. Now, why doesn't anyone see that SMTP+IMAP are an excellent protocol for doing publish/subscribe between machines, where real humans happen to also be able to (and already do!) PUBLISH and SUBSCRIBE?
The advantages of making a protocol an abstraction over email are manifold:
1. the messages are stored in the receiver's email inbox--a universal resource that everyone has [and understands the purpose of!];
2. all messages can be processed using the same "utilities" we use for email (backup utilities especially);
3. the ports for SMTP, POP3 and IMAP are almost always open inside corporate firewalls, just like the ports for HTTP;
4. and all messages you send through those protocols will get passed through email infrastructure (which is big and robust and reliable, and, most important, already exists)--and, in the process, can get forwarded, multiplexed across mailing lists, thrown out as spam, and all the other convenient things riding on email infrastructure gives you for free.