Its important to note that you generally would never want to use something like rabbitmq for read models. There is nothing wrong with rabbitmq here but the needs are different.
Read models generally have a requirement of in order delivery which is provided by catchupsubscriptions. They assure 100% in order delivery, this is done for simplicity purposes, handling out of order messages gets … complicated. You will not get this assurance from most queueing systems and its a real PITA to try to code around! There are however two even larger secondary problems with using something like rabbitmq for projections to read models!
The first issue which is rarely thought of is quite simple … How do you do … a replay? You should be replaying projections a lot. Any change to one would require a full replay… no?! I often give people the advice of replay all on every release (until it becomes prohibitively expensive!). This process is convoluted by having a queue in the middle yet is trivial if using a catchupsubscription! With a catchupsubscription you just say start at Position.Start and continue until … live … what level of coordination would you need on this with say rabbit?
The second issue is that very often there is a fan out here. There might be 14 consumers associated each at different locations in $all (its common to have even multiple per read model!) … How precisely will you model this with say rabbitmq? I guess there could be routing to varying queues but this quickly becomes nasty to deal with!
Keep in mind as well that event store currently also supports competing consumers which is a similar model to rabbit. When there are actions that you want to be taking (say emailing when event E occurs) this is another model that can be used without requiring bringing in further infrastructure.