RMI is the Java answer to RPC.
The only reason to use an RPC web service instead of RMI/IIOP would stem from the desire to have the functionality accessible to a wider variety of clients who may or may not be behind a firewall.
Not only is there more overhead due to the SOAP based marshalling/unmarshalling, but it makes it harder to deal with state. Your web service must be essentially stateless from a transaction perspective. If you needed to create a web service that was stateful, you could do it (...I have), but if you want to have a "transaction" that spans multiple calls to the service, you can't rely on the EJB container to handle it for you. You would need to write logic for compensatory transaction and even uglier, you'd need to deal with the issue of what happens if the web service client stops interacting with you mid transaction. There's no event model/call back mechanism to handle this sort of thing.
Keep in mind with EJB 2.0 you can get even more speed by making the interfaces local.That being said, that is not to knock web services. I think they're great, but they are not necessarily the solution to every problem. I expect web services will be treated by some developers just like XML was. When XML became "hot" people wanted to use everywhere for everything whether it made sense or not. Web services is simply another tool, just like a hammer. I just wouldn't use it to drive in a screw. :-)
