In contrast, the full STOMP spec fits on a page.
Of course they are vastly different in scope, but that is kind of the point.
There's a place for protocols like AMQP, there's a place for generic brokers like RabbitMQ, but there's also a place for far simpler protocols and simpler and/or specialized brokers. Lots of them.
For many applications being able to customize a simple, few hundred lines long, specialized broker is more useful than having all the extra capabilities you'd get from AMQP or a multi-protocol broker like RabbitMQ for example.
That's part of the reason you'll keep seeing a proliferation of these systems - it's trivial to implement a simple broker that can handle tens or hundreds of millions of messages a day on modern hardware (my last broker processed about 4-5 million messages/day using 10% of a single 2GHz Xeon core, written in completely unoptimized Ruby that took about a day to write), which means the barrier to writing your own and get something that fits your requirements exactly and where you understand every line instead of trying to find the ideal off the shelf solution is pretty low.
Now, there are many cases where an off the shelf solution to this is the right answer. The more complex your requirements are, the more critical proper failure handling is etc., or if external requirements involve speaking a complex protocol, the more attractive something like RabbitMQ gets.
But I doubt there will ever be a "one true system" for RPC or message exchanges, because the needs people are using RPC and message exchanges to address are so vastly different. You shouldn't look at whether or not these systems get widespread traction for that reason. What matters is if they are good at meeting the needs of their specific niches.