I feel that the point is not about the transfer representations but about the interaction model. REST makes sense as long as you can sanely map your interaction

I feel that the point is not about the transfer representations but about the interaction model. REST makes sense as long as you can sanely map your interactions onto simple modification of something that can be meaningfully described as "resource". For typical application that implements non-trivial bussines processes this means that you either expose low-level implementation details (ie. how you internally represent progress of some process) in your API or you implement "REST" API that is sufficiently far from what REST is supposed to mean that it stops to make sense to use that moniker. On the other hand SOAP is good match for such applications because it is simply an RPC mechanism, albeit with unnecesarily complex marshalling and transport layers underneath.