I think that lack is a strength. Lists, Maps, Booleans, Numbers, Strings. With these powers combined, you can create basically anything you can think of. Dates can be unix timestamps or ISO strings which are universal. Spatial data is a compound datatype anyway (plus, there are quite a few data representations depending on number of dimensions, cartesian vs polar, etc). The one datatype that JS could potentially benefit from is a byte array type, but even that can be accomplished with base64 "strings" or Lists of numbers.
To me, it's much better to let every company send error messages in the format that makes sense to them rather than having the One True Error that doesn't quite work for anyone.
My biggest complaints about JSON are syntactic. Optional comments, multi-line strings, and trailing commas would do wonders for day-to-day readability without significantly bloating the specs.
Agree with your points regarding comments and multi-line strings; don't like optional commas, though.
With respect to your "lack is strength" argument, I can't help but find this unconvincing. We all know JSON is derived from JavaScript object/array literal syntax; your argument is akin to retro-fitting the requirements for service payload serialization to the suboptimal de-facto situation with JSON.
To me, it's much better to let every company send error messages in the format that makes sense to them rather than having the One True Error that doesn't quite work for anyone.
My biggest complaints about JSON are syntactic. Optional comments, multi-line strings, and trailing commas would do wonders for day-to-day readability without significantly bloating the specs.