Should the "Geoservices REST API" become an OGC standard?

ESRI recently submitted their ESRI server REST standards to the OGC. Currently, the voting members have to decide whether they accept the proposal or not. As one of the contributors to the OSGEO-Live dvd, Cameron Shorter invited me to the discussion at Osgeo discuss list.
This discussion comes at an interesting time. Just a few weeks ago I did a session on geospatial web services in my company. The actual reason that we covered this topic is that there are two interesting (and diverting) trends happening at the same time:

1. The current OGC standards are finally taking off. Ever since our governement started serving their large-scale reference maps as publicly available WMS services, I see them being used  by many of our customers
   At the same time, I managed finding interesting data sets using CSW services for the first time, and the fact that view and metaservices have to be provided for INSPIRE III themes by the end of the year will probably mean that the shift to using services is finally taking off. 
2. On the other hand RESTful GIS services  have started popping up everywhere. ESRI's proposed Geoservices REST API is one, GeoREST is another one which I've enjoyed using. 

Actually my first thoughts when using ESRI's api was a sense of relief: I really enjoyed using these services. The fact that I can just tinker using an URL rather than having to use a special SOAP client was nice. My productivity as a programmer increased enormously. I couldn't figure out why anybody would want  to use SOAP-like services (without going in a semantic discussion).

So you would expect that I'd support the Geoservices REST API as an OGC standard? Well, no. Quite a large number of valid points have been raised: the name is bad, the existing reference implementation is commercial without available sources, ...

But I'd like to raise a different point: there are too many different services involved: the proposed standard comes in 8 different parts, all covering services which in my opinion unrelated. 

  12-054r2    GeoServices REST API - Part 1: Core
  12-055r2    GeoServices REST API - Part 2: Catalog
  12-056r2    GeoServices REST API - Part 3: Map Service
  12-057r2    GeoServices REST API - Part 4: Feature Service
  12-058r2    GeoServices REST API - Part 5: Geometry Service
  12-059r2    GeoServices REST API - Part 6: Image Service
  12-060r2    GeoServices REST API - Part 7: Geoprocessing Service
  12-061r2    GeoServices REST API - Part 8: Geocoding Service

This is the opposite of the unix philosophy: have one tool for the job. This is what in my opinion services should be about: have one service for every job, so one standard for every service. 

One tool for every job? Image source

I don't understand why a good feature service should also provide geocoding, maps or any other service. Yet these small tools will not be able to comply to the standard because they can provide only one service. 

So my proposal would be: break up the proposal. Check where new standards may be useful or where RESTFul implementations of existing services (and we already have a long list) are more appropriate. The services provided by ESRI prove that such an implementation really boosts productivity.

And actually while doing this, perhaps we should immediately consider using binary data where appropriate. I started off by saying that web services are finally being used. I did not mention WFS. This is logical. Nobody likes WFS. It is too slow. If WMS would contain an xml record for every pixels with an attribute for every color nobody would use it either. No, WMS sends a binary image. Why isn't  WFS doing the same and sending vector data in a binary form?