In the broadest sense, "RMI" is alive and well: there are many applications where one process exposes methods to be executed by another. The situation is slightly different when the term is used to mean the proprietary method of RMI that is built into the JVM, and has been around since the earliest days of Java. This method of RMI uses a protocol that is rather specific to Java, has no built-in support for propagating a transaction context or a security context, and is fiddly to route through firewalls. You can use the same RMI framework in Java with protocols like IIOP, which are language-agnostic and support transaction and security context propagation; but there are still problems with firewalls.
Traditional Java RMI is still widely used for remote management and monitoring, but I don't see it used much at the application level. It seems more popular these days to expose methods as web services, and invoke them using HTTP(S). There are frameworks for doing this in Java, and such services can be made language-independent.