AMQP is a wire-level protocol whereas HTTP is a general purpose protocol built on top of TCP/IP. What does that mean? It means with HTTP you have an enormous amount of overhead when using it to pass messages whereas AMQP is designed to do just this and is very fast.

AMQP is asynchronous whereas HTTP is blocking and synchronous by nature.

RabbitMQ, since it's built on Erlang has clustering built-in, just startup more nodes.

Reliability, with AMQP you can choose what level of guarantee you want when the message is delivered, messages can be persisted which means if you pull the plug from the server, by the time the server started again, that message will still be delivered (whereas HTTP will just drop that message), the publisher will receive a confirmation that RabbitMQ received the message and the consumer will notify RabbitMQ that it is done consuming that message - so RabbitMQ can offer certain guarantees that messages will be delivered whereas HTTP can't do that - at least not out of the box.

Exchanges allows you to forward messages to multiple participants (fanout) or have users subscribe to certain headers (topics) which allows you to send the message the exchange and let the exchange decide where to route the messages to.

The AMQP spec is open just like HTTP and is backed by some large companies: http://www.amqp.org/about/members

For more info see: https://www.rabbitmq.com/features.html

Probably related to this question Realistic situations where Message Queues should be applied?

I believe the best gain is reliability as well as scalability. Different services or workers can subscribe to tasks placed on the message queues. On the other hand with HTTP you would have to trigger multiple HTTP requests to those different services adding more overhead.

RabbitMQ has an RPC message option. The real advantage is that the workers can decide when to process the next message, which can balance load more evenly. With typical REST, you need a load balancer in front, which may not distribute requests where the most availability is, but as evenly as possible.

An advantage of HTTP+REST, is that you can fragment, and reverse-proxy portions of your public-facing, or rear-facing APIs as a whole, instead of as the fragmented parts they may be. You can otherwise break up your API based on features (or data fragments) over more monolithic approaches.

That said, look at your real needs, and only implement and add these kinds of complexity when you really need them.