Is REST the best thing there is?

This blog post is about what's important when creating an API. There are a few things which is sane, but there's a diagram which is, to be kind, misleading.

SOAP	RPC	REST
Requires a SOAP library on the end of the client (1)	Tightly coupled (2)	No library support needed, typically used over HTTP (3)
Not strongly supported by all languages (4)	Can return back any format although usually tightly coupled to the RPC type (i.e. JSON-RPC) (5)	Returns data without exposing methods (6)
Exposes operations/method calls (7)	Requires user to know procedure names (8)	Supports any content-type (XML and JSON used primarily) (9)
Larger packets of data, XML format required (10)	Specific parameters and order (11)	Single resource for multiple actions (12)
All calls sent through POST (13)	Requires a separate URI/resource for each action/method (14)	Typically uses explicit HTTP action Verbs (CRUD) (15)
Can be stateless or stateful (16)	Typically utilizes just GET/POST (17)	Documentation can be supplemented with hypermedia (18)
WSDL - Web Service Definitions (19)	Requires extensive documentation (20)	Stateless (21)
Most difficult for developers to use. (22)	Stateless (23)	More difficult for developers to use (24)
	Easy for developers to get started (25)

As for item (1) this is entirely true, but the item (3), is just blatantly false, we tend to keep forgetting that you need a library to use http.
Item (2) is not true, you are tightly coupled with the implementation of the RPC library (which you are in both SOAP and HTTP/REST) so whats the difference?
(4) is valid however a weak point. SOAP is basically XML+XML parser+XML validator and http client.
(5) is weird, what data isn't coupled to it self?
(6) This is myth with REST about exposing methods. So it matters what methods I use to make a call? Consider following code

public class MyResource {
    public String GET(String parameter){
          // return something
    }
    public void POST(Map <String,String> data){
      // do something with data
    }
    public void DELETE(String id){
       // delete id
    }
    public void PUT(String id) {
       // update id
    }
    // The rest here... All pun intended :)
}

So whats the difference here? Does a method name matter that much? You still need the URL just as you would anything else. This also applies to items (7) and (8).
(9) I must admit is convenient with REST, however still achievable with other means but a lot uglier so this I guess is a valid point. However in a real API this is a moot point.
(10) is true but in certain environments this is actually more loser coupling than a REST call, since you don't have to know content of the message but only that its a SOAP envelope. The envelope creates a loose coupling for some broker system since they doesn't need to know the type of message or the endpoint. Another important things is that if you use HATEOAS could actually result in more data sent because you have to manage the resource from the client, whereas if you use a SOAP this is managed by the server.
(11) if this a problem, then I guess you have larger problems.
(12) This just doesn't matter. In any large application this will be loads of URLs and confusing by its own.
(13) True, but a technical detail.
(14) Same as (12), just doesn't matter.
(15) If you build services as CRUDs then you are creating unmaintainable services/APIs.
(16) True but moot point.
(17) Again moot point.
(18) Again, there's no CRUDs. Code which based on this is automatically unmaintainable.
(19) True, but in there's WADL for Rest too. This is a nice feature which RPC usually lacks, however using a interface for RPC is not bad either.
(20) Wrong. You need as much as you need for a REST service. If you don't then you don't know how to code. Sorry partner. Just because you use REST doesn't remove the need of context of what the resource do, supposed to be and what relations it has. If you build you application on this premise it will be buggy and error prone with time. It will also add unnecessary costs to maintain it.
(21) This is just irrelevant point.
(22) Well if you have good tooling, I'd say SOAP is the easiest, though I can agree it could get unnecessary complex. I also think that SOAP is trying to do too much which is not needed.
(23) Again irrelevant point.
(24) Again with good tooling this could be as hard/easy as using SOAP.
(25) This depends on the RPC implementation. However its easy to hide it with abstractions.

A protocol is NOT an API. REST is a deceptive technique. If you have a web application and you want some sort of database without anything in between REST could be a choice. However if you want to do something else, use other everything else but REST. REST doesn't create an abstraction as it's advertised to do because the mechanics of retrieving and getting data is now on both sides of the protocol boundary. This creates a mechanic coupling, stuff knows too much about other stuff. I bet that we'll se a lot of "legacy" problems in the future where rest apps are becoming a real problem. There is a lot of problems with the REST proclamation and of its benefits. My view on that is that REST is the answer on another problem which is born out of inherit problems with the inability to code correctly (and that differs on programming paradigm, language and framework).

My point is that, it cannot and should not matter how you retrieve data, just that you actually did and what that meant for that particular code. If the protocol implies mechanics on meaning you are mixing things which should not be mixed.