PUT is used when you know the URL you are creating and you can send a whole resource. This, by convention, has been interpreted by many to mean updates, but not everyone agrees. The Basecamp API for instance uses "PUT /todo_items/#{id}/complete.xml" to mark a TODO item as complete. Is this creating a new "complete" resource, or updating a "todo_item" resource? Either way, when trying to make an API fit the REST style, one must fit everything into the standard verb / filesystem-like mold. With plain-old RPC, you name your methods whatever makes sense to you, using your time-earned experience in designing regular libraries, and you don't waste a moment on these nitpicky decisions.
The lack of consistent client support for PUT and DELETE further complicates this issue. As you say, you can abstract away the emulation of these verbs, but what library are you speaking of? A single-purpose solution to wrapping a particular REST interface? Or a one-size-fits-all REST wrapper that works with any server? I'm not sure the latter is possible, since there are once again multiple ways to do this - "?_method=PUT"? X-HTTP-Method-Override? Or something else entirely... it's not standardized, and REST isn't a spec, it's just a style, so everyone does it their own way. All of this so that we can write "PUT" at the beginning of the HTTP request line instead of further down or to the right? What is the actual benefit to all of this extra work?
The biggest issue with parameter-passing style is the lack of a standard way to pass complex data structures. It's as if every function took only a single argument, a string, and had to run a regex on it, splitting the results on delimiters, each in its own special way. If a regular software library were written this way, it would be appalling. At least PHP gave it a shot, with its arr[]1=&arr[]=2... syntax, but nobody's going to standardize on that, since query strings are unfashionable now, and nobody likes PHP anymore. I honestly think we should go back to query strings and stop embedding data in URLs because at least you get named parameters. And if you subscribe to the HATEOAS camp, they're more RESTful since we already have one standardized, well-documented way to provide clients all they need to build them (HTML forms).
You're right, just because people don't use something consistently doesn't mean you should throw the whole thing out. I didn't mean to imply that. What I stand by, however, is that HTTP status codes were not designed for APIs, and that as a result they are guaranteed to be used inconsistently when used for the purpose of designing APIs. At least with all-custom error codes there's no expectation that everyone will interpret the HTTP standard correctly as applied to a problem it was never intended to solve.
The lack of consistent client support for PUT and DELETE further complicates this issue. As you say, you can abstract away the emulation of these verbs, but what library are you speaking of? A single-purpose solution to wrapping a particular REST interface? Or a one-size-fits-all REST wrapper that works with any server? I'm not sure the latter is possible, since there are once again multiple ways to do this - "?_method=PUT"? X-HTTP-Method-Override? Or something else entirely... it's not standardized, and REST isn't a spec, it's just a style, so everyone does it their own way. All of this so that we can write "PUT" at the beginning of the HTTP request line instead of further down or to the right? What is the actual benefit to all of this extra work?
The biggest issue with parameter-passing style is the lack of a standard way to pass complex data structures. It's as if every function took only a single argument, a string, and had to run a regex on it, splitting the results on delimiters, each in its own special way. If a regular software library were written this way, it would be appalling. At least PHP gave it a shot, with its arr[]1=&arr[]=2... syntax, but nobody's going to standardize on that, since query strings are unfashionable now, and nobody likes PHP anymore. I honestly think we should go back to query strings and stop embedding data in URLs because at least you get named parameters. And if you subscribe to the HATEOAS camp, they're more RESTful since we already have one standardized, well-documented way to provide clients all they need to build them (HTML forms).
You're right, just because people don't use something consistently doesn't mean you should throw the whole thing out. I didn't mean to imply that. What I stand by, however, is that HTTP status codes were not designed for APIs, and that as a result they are guaranteed to be used inconsistently when used for the purpose of designing APIs. At least with all-custom error codes there's no expectation that everyone will interpret the HTTP standard correctly as applied to a problem it was never intended to solve.