YAML seems more preferable, since it would be far more readable when STDOUT is the shell.

Oh, and JSON is a functional subset of YAML, so you'd still be able to output as JSON and a YAML parser will read it.

Except what about Dates? Or apps were floating point precision is important? Or needing to deal with very large integers? Also, have you thought about how large the output would be for ls as JSON? Think about the I/o usage if every time you invoked ls it had to do a deep walk of the file system to get all the possible data ls might output with all its command line arguments.

JSON doesn't support behaviour (methods). They are very useful for composing programs IMO.

Methods are useful to organise and abstract programs, they're really quite bad at composition. Many functions operating on the same primitives is much more composable than small sets of functions operating on their own custom primitives.

Behaviour could be implemented by shell commands. That way, if you wanted to implement a method for a particular object, you could just write a binary/shell script/whatever that reads the object from stdin and writes its result to stdout

Then you'd need a JavaScript interpreter. Which would be terrible.

Well, it doesn't have to be JS specifically. In theory, it could even be a piece of machine code.

if the deserialization mapped to a system wide type system then the methods could be mapped in at that point.

And a small number of tools for composing JSON.