I'll admit to being completely ignorant about the benefits of using SOAP to communicate between servers. However I can say that for server->client communication it is the worse data representation I've ever had to work with and I genuinely hope we see the end of it. JSON maybe not be perfect, but it's so much better at delivering a structured data model then xml is.
I think I'd like JSON as a data representation a lot more if schemas for it were more prevalent. I've noticed it's a lot harder to generate valid JSON -- or rather a lot harder to escape data. With XML, this is fairly trivial. Granted, my use case is considerably different from most.
The other idea from SOAP I'd love to see applied to ReST is a descriptor document for the API. Given how poorly many ReST APIs are documented, I do miss the good 'ol WSDL. Plus, it gave me some measure of security that the API didn't change.
The strictness in generating valid json is exactly why i like it so much. I've worked with too many SOAP services with nodes and attributes thrown lazily around the document simply because xml is so unstructured. I do agree however that json could use a few more built-in data types to handle more complex use cases.