The Windows registry/powershell approach has the niceness of passing pieces of data instead of one big blob of text that has to be re-parsed at every step, but with the drawback of verbosity and fussy static typing.
Being able to directly pass s-expressions between between programs without the format/parse/typing hokey-pokey of Unix and Windows would be nice.
Also, ZetaLisp and Common Lisp have way more types than those supported by S-expressions. For example, they have real vectors/arrays, structures, and full objects.
Don't assume all of the Lisp world uses just the subset of Scheme used in the first couple chapters of SICP.
Genera did not have programs, it is all just function calls.
There was a multi-user LMI Lisp machine that ran Unix concurrently, that used streams to communicate between the two Lisp and one Unix processors: http://www.1000bit.it/ad/bro/lmi/LISP-MachinePR_Photo.pdf
Formats for inter-process communication are hard and far from a solved problem. Just look at what has come out in the past 10 years: Thrift, Protocol Buffers, Cap'n Proto, FlatBuffers, SBE, probably twice as many others I haven't heard of.
Being able to directly pass s-expressions ... would be nicer than putting an alphabet soup of parameters on one program to have it output text in just the right way for the next program to re-parse it with another alphabet soup of parameters.
I'm not saying that this is the one true way. I'm just agreeing with the article that there is a lot of room for improvement in how things get piped and config-ed in *nix.
If I had to guess, I'd say the issue with JSON and the like is how to deduce types (and the limited types available) combined with the issue of special characters in names and strings.
XML goes a long way towards fixing that, but at the cost of a lot of extra bloat. A binary format with a nicely defined header might work, but those formats tend to not be so good about inserting stuff.
There is something to be said in favor of plain text. If all solutions suck, go for the simplest and most flexible solution.
JSON is just arrays, objects, bools, numbers, strings, and null.
How are they "close"?
You could do what you describe with JSON too – it’s just encoding and decoding. Would you therefore be able to claim that JSON is capable of transmitting, say, tabular data? Of course not.