We should not forget about a "devil in the details". In the dominant majority of cases, the client of the "stateless process" is another service/process in the Cloud. That is, according to ZapThink, a working service/process may not be stateful while the consuming service/process may... This is what obsession is doing to us.
At the end, ZapThink lists "some pointers to architecting a partition-tolerant, RESTful BPM application":
1) "Separate the resources that build process applications from the representations of those resources". We are interested in the process applications in the Cloud, not in the resources that build them, aren't we? "... the persistence tier doesn't host a process engine, it hosts a model-driven resource that generates stateless process applications to run on the elastic application tier" - probably, ZapThink has to recall that a term "process" means an interconnected logical chain of steps. If a client of a process has to pass the state constantly to this "process", it becomes a part of the process, which contradicts the fundamentals of the notion of a process and totally unacceptable.
2) "The application tier acts as the client for such process representations, and as a server that supports the clients of the process." Wait a minute, up to this moment we know only a process application and representation of the resource - where a "process representations" came from and why a process application has to support clients of the process; the clients are independent and self sufficient entities.
3) "Separate UI representations from application state representations" - I hope this is just a typo, otherwise I'd like to see a UI in the Cloud. I assume that the UI was meant as the client interface.
4) "Use a lightweight, distributed queuing mechanism to address client uptime issues" - and if the client issues are not lightweight, do not use the Cloud/ RESTful BPM... correct?
5) "For processes that require heavy interactions among multiple actors, follow a peer-to-peer model" - here we are, back to the future: peer-to-peer instead indirection and subjective judgement on lightweight/heavy interactions.
In the final "The ZapThink Take" section, ZapThink opposes Web Services-based SOA to REST-based SOA. If REST is a representative state transfer and abstraction of elements/resources with no mechanisms that make this abstraction an architecture, i.e. REST is a very specific technology with a rich philosophy behind it, what may be a REST-based SOA? Service-oriented Architecture is technology agnostic and independent from mechanisms and content of transfer, at least, this is what ZapThink taught in 2007 when I was certified as a ZapThink SOA Architect. Probably, you have noticed that for the last couple of years debates about REST as SOA almost vanished from the Web. In any case, running an automated business process with no state requires moving a significant amount of data - the state itself and the results of the all steps of the process - via messages; REST (whatever it is) does not seem the right media for large data transfer while Web Services do though the letter are not the only communication interfaces that may be used for automated BPM within and outside of Cloud.
After all these comments, should I say - leave RESTful BPM to rest until it gets in order, at least, for Business to understand what is happening with its processes in the muggy Cloud?