The web services do allow a loosely coupled architecture. With RMI, you have to make sure that the objects stay in sync in all applications, which means that you always have to deploy both of them at the same time even if only one of them is changed (not necessarily, but it is required quite often because of serial UUIDs and whatnot)
Also it is not very scalable, which might be an issue if you want to have load balancers.
In my mind RMI works best for smaller applications, that are not internet-related. I've used it to have a java application that handles electronic communications

Whether you use Web Services or a more "native" approach depends on the environment as well. If you have to pass through a proxy or some corporate firewall(s), Web Services are more likely to work since they are relying on HTTP only. RMI requires you to open another port for your application which may be difficult (not technically, though) in some environments...
If you know that this issue is not a problem, you should consider using RMI. SOA does not depend on technology so much as on good service design. If you have an EJB container, you can call session beans via RMI and additionally expose them as web services, if you really need to, by the way.
The performance depends on the data that you are planning to exchange. If you want to send complex object nets from one application to another, it's probably faster with RMI, since it's transfered in a binary format (usually). If you have some kind of textual/XML content anyway, web services may be equivalent or even faster, since then you would not need to convert anything at all (for communication).

Socket vs. REST Web Service performance


Its hard to imagine that REST is faster than a simple socket connection given it also goes over a Socket.
However REST may be performant enough, standard and easier to use. I would test whether REST is fast enough and meets your requirements first (or one of the many other existing solutions) before attempting your own Socket solution.

RMI
Feels like a local API, much like XMLRPC
Can provide some fairly nice remote exception data
Java specific means this causes lock in and limits your options
Has horrible versioning problems between different versions of clients
Skeleton files must be compiled in like CORBA, which is not very flexible
REST:
easy to route around firewalls
useful for uploading files as it can be rather lightweight
very simple if you just want to shove simple things at something and get back an integer (like for uploaders)
easy to proxy security behind Apache and let it take the heat
does not define any standard format for the way the data is being exchanged (could be JSON, YAML 1.0, YAML 2.0, arbitrary XML format, etc)
does not define any convention about having remote faults sent back to the caller, integer codes are frequently used, but method of sending back data is not defined. Ideally this would be standardized.
may require a lot of work on the client side caller of the library to make use of data (custom serialization and so forth)
In short from here
web services do allow a loosely coupled architecture. With RMI, you have to make sure that the objects stay in sync in all applications
RMI works best for smaller applications, that are not internet-related and thus not scalable

Ref:

http://stackoverflow.com/questions/100993/rmi-vs-web-services-whats-best-for-java2java-remoting
http://stackoverflow.com/questions/5026952/socket-v-rest-performance