HTTP and REST give you several ways to make requests (PUT vs. POST? Fall back on POST for clients that don't support PUT? How?)
PUT is used for update operations and POST generally for create. Your library will abstract away the "client doesn't support sending PUT" so you don't deal with it. Same way XML-RPC libs abstract away the ugly portions of XML-RPC.
several ways to specify parameters (URL path fragments, query strings, headers, or POST data?)
Yes, there's more than one way to do that. Generally a service's documentation tells you what to do, so I'm not seeing the issue, but I concede that someone might find fault with that.
and a set of standard errors that you do not control and which are not used consistently
Whereas XML-RPC gives nothing, and everything is re-invented every time. Again, if that's a better solution for you, awesome, but for me the "some people use HTTP status codes to mean different things" isn't a reason to throw the whole thing out.
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.