I've seen people question ESRI's decision not to use GeoJSON in their server API spec (note: sometime after I wrote "If it's a #GIS spec, you can be sure there's a click-through agreement to read it" the click-through was thankfully eliminated). Since we in the GeoJSON working group haven't gotten around to actually standardizing the format through the IETF (for example, the body that published RFC 4627 on JSON), it's completely forgivable. The CC-BY license on the GeoJSON spec is clear on rights to use the work itself, but perhaps not clear enough to some about the rights to "GeoJSON technology". Myself, I don't consider GeoJSON a technology, but it's courts that decide, not me. One must also remember that ESRI's spec is the documentation of a web API that, while maybe not written before the GeoJSON working group started, shipped before we had a published GeoJSON spec and well before it got serious traction.
I do like a couple aspects of ESRI's JSON geometry representations. Geometry objects aren't primarily determined by their "type", but by their properties: an object with an "x" and a "y" is a point, an object with "paths" is a polyline, an object with "rings" is a polygon. We considered this "duck typing" approach when drafting the GeoJSON spec, but explicit typing won out instead. In addition, with the exception of point objects, the coordinates are represented in a way that's entirely compatible with a GeoJSON reader. It's a shame about the points, but otherwise there's a lot of common ground. ESRI JSON features look a lot like GeoJSON features, too.
I'm not sure what to say about the rest of the spec. It's awfully large and I get a flash of OOXML deja vu that may yet pass. It's certainly different. I'm looking forward to other reviews and analysis.