You could do this using regular email, but regular email is hard to wire up to programs and isn't very flexible (eg. it's relatively hard to set up new email accounts).
With these messaging protocols, programs can just create channels for themselves and set up all sorts of interesting communications protocols -- eg. point to point, publish and subscribe, one to many etc. And it's (relatively) reliable so you know the message is going to get delivered.
That doesn't mean this isn't worth bringing to a larger audience.
The one thing that has really held back the broad adoption of AMQP is the delay behind the release of the 1.0 version of the protocol. Now that we have this under our belt we need implementers such as RabbitMQ, StormMQ, Microsoft, INETCO etc to add support for AMQP 1.0. Finally, we need native AMQP clients installed by default and widely supported by OS and hardware developers, put simply, we need the full participation of the main operating system stack suppliers such as Microsoft and Redhat.
Luckily enough, both RedHat and Microsoft are members of the AMQP Working Group. I assume that they will release native clients and thus pave the way for broad adoption. It is the growth of pervasive AMQP clients and a strong and healthy developer community that will drive adoption and general acceptance of AMQP.
Next year HN projects: Nxxxx.js, MxxxxxDB and RabbitMQ.
Firstly HTTP is unreliable because there is no guarantee that the website is up at any particular point in time. In other words you couldn't write a reliable program that depended on fetching data from a website because the website might be down when you requested it. You could try to wait and fetch the data later, but that would be effectively building another protocol on top of HTTP to make it more reliable. I have no idea about IIOP/CORBA but perhaps it added more reliability?
AMQP isn't completely reliable. I mean, if you send a message to an AMQP broker and it's committed, that just means it's saved to some presumably reliable resource, eg. to a harddisk. If a plane falls out of the sky and wipes out the broker, then it's not reliable. [You can, if you have enough time and money, set up AMQP so that it would be reliable even against aircraft incidents]
I don't think in this respect that AMQP is more reliable than SMTP. But it's a lot more convenient than SMTP for what it's designed for: ie. messaging for programs. Getting email out of and back into programs is a whole lot more complex than just setting up an AMQP binding.
The issue you bring up with HTTP is actually related to HTTP being synchronous rather than unreliable. If you wrote your program to fetch data by sending an email, it would probably work even if the SMTP server that had the data was down: your local SMTP server would store your message and forward it when the destination server came back up.
For example, as of RabbitMQ 2.6, there is active-active broker clustering: http://www.rabbitmq.com/ha.html