It isn't that S-expressions can contain code, it's that they are so simple that based on a very simple syntactical rule set certain tokens can be interpreted as code or data and because of that you can easily "tokenize" pieces of "code" to make it "data" and vice versa (that's a really flexible feature). Kind of notable that S-expressions are an integral part of the language and not just a "data format" of the language...
You could easily invent a programming language expressed in JSON literals, it just wouldn't be quite the same as javascript. I'd argue that sexprs are simpler because they only use one container type (alists and plists are merely conventions, not baked into the grammar). However, JSON's omission of the symbol/string distinction is one argument the other way.
Yes, you can, probably not too different in nature to Racket's syntactical sugar with using "[" (square brackets) to make reading the LISP code easier... And yes, your argument for their simplicity is actually what I was trying to express (much less successfully than you did).
That might be a slightly amusing syntactical overlay on Common Lisp. Hash-tables are a bit manky to deal with directly IMO; setting up a reader macro in JSON-esque syntax might be quite usable.