REST is focusing on small commands like GET this, PUT this, POST that, DELETE X. It's very low level. RPC calls are more focused on a single thing at a higher abstraction level, as it doesn't have to match HTTP commands like get/put/delete. E.g. to obtain the data for a single page, one could do in REST several GET calls and for the actions on the page several POST/PUT calls. In RPC, you might want to call a single method which returns all data of a given page and one RPC call to perform the actions of the page. As you can see it's a different way to work with a remote service: REST is lower level, more chatty but also more flexible in the sense that you can combine building blocks to form new features. RPC is focused on doing things on a higher level and often requires you to add a method or several methods for a particular feature, no re-use.

I mean, is there really a fundamental difference between mysite.com/users/username and mysite.com/getUser.php?username=username?

It's not a good example, as the 'getuser' call isn't really what you'd do in the RPC sense: why do you call get for a user? only to obtain the user information? Or to obtain the user information as part of a screen/form/page which also has other information? (so in a sense you'll do several get calls) In the RPC world you'd then call 1 method still, in REST you'd simply do several get calls, one for each information element which together make up the information for the page.

I have to add that this is a VERY old debate: I remember hot battles being fought all over the internet when webservices (which typically offer an RPC style api) were all the rage and REST services emerged and were burned to the ground as 'too chatty, they'll kill your server!' and vice versa were seen as 'the simple form to build a webservice without a lot of work'.