Definitely not "solved", just made more explicit, kind of like a warning sign in the road. A while ago I worked with an RPC system where the RPC calls looked just like normal function calls... everything worked well, until it didn't.
Anytime a computer program consumes a potentially scarce resource (e.g., network, disk, database, etc), there should be some warning-sign or flag raised to the developer. RPC hides that, whereas REST makes it more explicit. So much of programming is social, and the mechanics of REST, even though theoretically identical to RPC, raise many social flags warning of danger ahead.
Or in other words, there is absolutely no technical justification for using this overly verbose and unmaintainable mess. It's just some vague philosophical thing that has no clear benefits. Like OOP.
I doubt that these qualities are actually achieved. Generally I don't think there have been many (if any) languages where excessive verbosity built in to the language has proven to be a good idea. Think COBOL, Java...
It's worse if not only statements are longer, but you are actually forced to treat similar things in very different ways (like URL resource vs query string vs post parameters). It just increases code complexity without any clear benefit.
I'm not really sure I see the difference. One of the first things done is to wrap all the calls to the webservice in some kind of API (often using a pre-existing library), which puts you back exactly where you were with calling a function which happens to make a web request.
Anytime a computer program consumes a potentially scarce resource (e.g., network, disk, database, etc), there should be some warning-sign or flag raised to the developer. RPC hides that, whereas REST makes it more explicit. So much of programming is social, and the mechanics of REST, even though theoretically identical to RPC, raise many social flags warning of danger ahead.