You can run every actor in a separate thread or even in a separate machine, making the whole system highly scalable. Whether you'll consider that a new paradigm or not, is question of definitions.
Remote method invocation is inherently a bad idea, because real world remote systems have significant latencies. Ordinary function call is few processor cycles. Network function call is few billions of processor cycles. While abstraction is a good thing in general, that kind of abstraction is not a good thing.
That's the reason why remote calls today are using explicit syntax, API and so on.
But with actors it's expected that sending a message to actor is something that takes some time. So you have a clear separation between ordinary function calls and actor messages.
Of course it's still a lot of difference between sending message to a thread or sending message to another machine. So take that with a grain of salt. But at least you can utilize multicore CPUs.
Although I'm not sure what you really mean by "remote method invocation", the idea of remote method invocation in OO systems should be impossible or incredibly difficult considering the semantics of a method call.
Method calls are synchronous and they are not allowed to fail under any circumstance. But in the context of distributed systems you have to choose between at most once or at least once delivery which are semantically incompatible with OOP style method calls.
Your methods will have to be written with the expectation that they are called multiple times or maybe not at all and most OOP code doesn't satisfy these expectations because the OOP model doesn't require it. If you extend the OOP model with message semantics of the actor model then what you get is not just OOP+messaging. It's the actor model.
Also you may have misunderstood something very fundamental. The benefit of paradigms isn't to be completely different. It's that everyone that shares a paradigm follows the same design philosophy. Imagine a mixed code base consisting of traditional OOP (with locks), actor model, async/await, promises. It would be very difficult to understand and sometimes it isn't obvious which of these is used. Some functions are asynchronous or they may fail but you may not know that because every single line could do a different thing. They may even be incompatible with each other. If you follow a single paradigm instead of many different ones you can avoid a lot of confusion and wasted work.
There have been dozens or hundreds of things called "remote method" or "remote procedure" or "remote function" invocation. However, not a single one of them has overcome the fundamental problem that you can not have something that is semantically identical to the function call presented by programming languages, because programming language functions simply do not have the concept that you are accessing it over a network, and they take heavy and critical advantage of the resulting simplifications.
Someone more clever than wise may stand up and point out that technically even a local function call is unreliable in many of the same ways that a network call is. However, even if many of the same problems can theoretically arise, the distribution of the problems are fundamentally different, which is why you do not guard every single function call in your program for all the network-type errors, and it generally works, whereas if you program that way in a networked environment, it generally does not work.
Personally I've come to prefer messages very strongly to "RPC" as the foundation of a system. Messages can trivially implement an RPC-like system, but RPCs can not implement a message-like system. Even if you implement an RPC called "SendMessage", you're still adding synchronization on the RPC system sending over the call and waiting for the response. Among other things, but that's the big one.
It’s impossible to make RMI behave exactly like local method invocation. It introduces many error cases and performance challenges you don’t normally have to consider.
The big difference is that you can pass an object to a method of another object, but you can't send an actor through a message channel. That jives with threads because a thread can't climb in to the stack and get passed through another thread.
