In your preferred way, data is exchanged over HTTP which uses percent encoding to pass data. I'm stating that a serialized object, in this case JSON, provides more benefit.

Both require overhead to encode and decode, but I believe that serializing your data allows for a more consistent exchange that (provided I am understanding how you post and retrieve data) actually may reduce size, increase the variance of what can be transmitted, and remove specific limitations that HTTP may encounter.

I'm genuinely curious if I am missing something.

I'm sure I could find myself in a position where I would want to standardise on JSON as a container for requests/responses, though see my last paragraph about Atom.

That said, my instinctive reaction against using JSON as an envelope is that it adds a layer of abstraction (and potential obfuscation) that I don't see an immediate benefit for. It may hark back to my experiences with SOAP. My mantra is to exploit the existing protocol to its fullest before extending it, and to do the simplest thing before adding complexity.

Let's presuming we're still at a basic level of interaction through a website. Treating something as a form with fields such as name="user[email]", name="user[password]", name="user[telephone][mobile]" etc, seems more discoverable to me, as a developer at least.

For one thing, I know there is no JSON translation layer to go through. For another, I can get a server to generate a form that I can use to test the interface quickly and easily. To do the same with JSON would require me to have some JS intercepting the submit event so that it can convert the contents to JSON before posting. So now I can't use a terminal based browser to do my testing. Which means maybe I can't automate some testing strategy so easily.

If we're talking about a more sophisticated RESTful API, I would probably choose ATOM over JSON, because ATOM is built on XML and therefore is defined by a schema and can be interpreted by the browser. Specifically, it provides the rel attribute for discoverability. JSON payloads can implement this too, but you have to choose your extension.

In fairness, if I were doing a RESTful API, I'd probably be thinking about being able to implement interfaces for ATOM, JSON, and HTML, plus whatever cool new thing is just around the corner.

I'll agree that your way definitely provides less abstraction, and my viewpoint doesn't perceive jt in that way. That being said, I've made a similar case against ORMs, so I understand your position.