First, regarding "call a method or function on someone else's machine" -- that works only if the service you're calling is a standard one that resides on someone else's machine, or code someone else wrote and happens to be running on their machine. With Serverless, you write the code that runs on someone else's fleet of machines.
Furthermore, with RPC for a service you're creating (your own service), you need to manage the fleet of servers that runs the code that provides the RPC service. Calling code needs to know the hostname or IP address where the RPC service is running, and if it's a fleet, you need to manage load sharing of some kind. You need to estimate how many servers you need in the fleet, and pay for the excess when you're not using it, or handle the issues if it's not big enough. You need to manage the process that serves the RPC on the server fleet. You need to deploy it to the fleet with a Continuous Delivery strategy.
With Serverless, you just write the code, attach the trigger, and let the "serverless" service manage and allocate the resources to run it. (OK, you still have to manage a CD strategy!)
Furthermore, RPC is similar to only one type of Serverless invocation: direct ones, from the serverless API. In contrast, serverless invocations can be tied to events in the cloud, such as stores to a database or filesystem or queuing data on a queue. With RPC, you need to write the code to detect the event and invoke the RPC call. With Serverless, you configure it and let the system handle the details.
One might object to the term "serverless", since of course there is a server -- but it's a server (or actually, a fleet of servers) you don't need to know about or think about, and that's the point of the name.
For a great explanation, see http://martinfowler.com/articles/serverless.html