Email has different needs than do web pages, thus the protocols are different. Could one implement email over HTTP? Sure! But what, exactly, will be the benefits and costs? And then there is history. Unless the benefits are extremely compelling it will never be worthwhile to upset the entire email infrastructure.
A large number of people consume e-mail using HTTP, so it has in many cases replaced IMAP and POP. We also send e-mail using HTTP, both through web-mail systems and ad-hoc forms. This replaces SMTP-for-sending.
All that's left really is the server-to-server SMTP, and if the distributed social networking protocols (OStatus etc) take off, then SMTP will have been partially replaced as well.
The main issue is that aside from OStatus, none of these are remotely close to being standardized. So automation is hard. This is good for preventing spam but bad for many legitimate things.
But I take issue with the idea that replacing IMAP with HTTP would in any way upset the email infrastructure. Changing the client protocol does precisely nothing to the infrastructure, unless you choose also to replace SMTP completely. I could write my own server for my own email account, with HTTP for the client, and as long as it used SMTP to send and receive in the network, no-one would see any difference.