Message queuing is old, boring, and well understood. The same kinds of people that are trying to convince us that REST is a huge improvement over WS-<star> (despite the fact that once-RESTful protocols are becoming increasingly similar to WS-<star>) are trying to convince us that XMPP is to message queuing as REST is to WS-<star>.
More cynically, XMPP vendors generally give everything they have away in hopes that somebody with money will buy support for it. Since customers of message queuing products are people with money, it is only natural for people to hype XMPP as the "worse is better", cheaper alternative to "enterprisy" MQ products in hopes of having some money fall into their pockets.
Less cynically, the people hyping XMPP understand it very well from their personal experiences with chat systems and "chatbot" like applications including Twitter. It is easy to say "hey, if a computer can IM me, I bet a computer could IM another computer." It is a little tricky to abstract that into "hey, that is the same thing as that old, boring message queing stuff," and anybody that gets that far realizes it's not that exciting to blog about.
And this is what scares me when I read about things like vertebra (http://www.slideshare.net/ezmobius/vertebra) - how in earth could a company that sells cloud computing not already have a message queueing architecture!
It is pretty common for a RESTful protocol to end up with batch-fetching and batch-updating operations. Once you add those operations, you've already violated the "uniform interface" constraint and removed all the benefits (primarily caching, authentication, authorization, and parallelism) that derive from the uniform interface constraint. Once you have batch-fetch and batch-update, those two operations can generally do everything that you usually did via individual PUT/POST/DELETE operations. So, why do you need the separate PUT/POST/DELETE operations at all? It is just more surface area for you to maintain.
Now, maybe you want to combine your batch-update and batch-fetch operations into a single "batch-update-and-fetch" POST operation. Well, that is exactly what WS-* does.
On the flip side, sometimes instead of batching you want to fetch or update only parts of individual resources via some extension to partial GET requests and or a PATCH method. There is currently no uniform interface for those so, just like in the case of batching, you lose all the uniform-interface benefits.
Now, let's say you want to combine your partial-resource operations with batch operations over multiple resources to reduce the number of requests you receive and/or the reduce the aggregate size of requests, so you add the ability to do patching and partial-fetches to your batch-update-and-fetch mechanism.
Now take a step back. Doesn't your batch-update-and-fetch-with-patch-and-partial-fetch look a lot like SOAP with WS-ResourceTransfer? It will probably look a lot like SOAP; not even the newish SOAP 1.2 that actually is somewhat HTTP cache friendly, but old school RPC-only SOAP + WS-ResourceTransfer.
Look at Google's GData and OpenSocial's RESTful API for examples.
And, that is totally ignoring anything to do with transactions.
Take any WS-<star> specification, and you can probably find one or more ad-hoc proposals for adding similar features for RESTful protocols. For example, AtomPub is adding a mechanism that is almost exactly like SOAP-with-attachments, but more limited. The various HTTP message signing mechanisms like those found in Amazon's web services or the one in OAuth (and OpenID? I forget if there is a different one for that) are analogous to the various WS-Security stuff. As another example, I've seen a couple RESTful protocols that tried to define something like a simpler WS-Policy.
I don't think that the WS-<star> stuff is that great either; a lot of it is really complex. But, WS-<star> stuff is all decomposed in ways that make it relatively simple to combine just the parts you need together. SOAP 1.2 isn't complicated at all. WS-Policy and WS-Security and other stuff is more complicated than it needs to be, but it isn't so complicated that it needs to be totally redone anew. And, a lot of it can be (and is) subsetted pretty easily.
What you say makes a certain kind of sense if you think of REST as a protocol. But REST is not a protocol.
There seem to be quite a few people these days who think that REST means nothing more than "uniform interface" and/or "resources". But that's only part of the picture.
"REST is defined by four interface constraints: identification of resources; manipulation of resources through representations; self-descriptive messages; and, hypermedia as the engine of application state."
P.S. I'm not sure why you think batch operations are missing from REST. GET/PUT/POST/DELETE can apply just as well to collections as to individual resources.
More cynically, XMPP vendors generally give everything they have away in hopes that somebody with money will buy support for it. Since customers of message queuing products are people with money, it is only natural for people to hype XMPP as the "worse is better", cheaper alternative to "enterprisy" MQ products in hopes of having some money fall into their pockets.
Less cynically, the people hyping XMPP understand it very well from their personal experiences with chat systems and "chatbot" like applications including Twitter. It is easy to say "hey, if a computer can IM me, I bet a computer could IM another computer." It is a little tricky to abstract that into "hey, that is the same thing as that old, boring message queing stuff," and anybody that gets that far realizes it's not that exciting to blog about.