While OO in theory can map pretty well to REST, it takes a lot of metadata and careful thought to turn those objects into resources. Making an RPC application is much easier. This is one of the killer features of SOAP/WSDL. I can take my business service and build a web service out of it with very little effort (I assert that there are non-evil ways to do this, but thats another story). I can then be interoperating with a .NET application in just a minute or two. Or I can take a WSDL, generate a set of objects, and just write some glue code between my internal objects and the web service objects.
Building the RESTful equivalent isn’t nearly as easy IMO. (At least for Java).
Dan is right: weirdly enough, building your own protocol using Web services is a lot easier than understanding and using HTTP correctly. REST and RESTful HTTP are not easy, especially not for most enterprise developers who are used to remoting objects (including myself). But of course the home-grown protocol exposes none of the benefits of HTTP — which IMO means that investing the time and effort to learn and apply RESTful HTTP is an investment that pays off very quickly.
The question you gotta ask yourself is: “What are the benefits of HTTP?”. And if you make sure your home-grown protocol actually takes advantage of the benefits of HTTP, then I think you’ve done the right thing. I don’t care what you call the architecture.