For you, perhaps. For me, the former is denser, but crossing into a "too dense" region. The JSON has indentation which is easy on my poor brain. Also, it's nice to differentiate between lists and objects.

But, I mean, they're basically isomorphic with like 2 things exchanges ({} and [] instead of (); implicit vs explicit keys/types).

Yeah. I don’t even blame S-expressions. I think I’ve just been exposed to so much json at this point that my visual system has its own crappy json parser for pretty-printed json.

S expressions may well be better. But I don’t think S expressions are better enough to be able to overcome json’s inertia.

even as a fan of s-expressions (see my other comment), i have to agree. but the problem here is the formatting. for starters, i would write the s-expression example as:

    (urn:ietf:params:acme:error:malformed
     (detail      "Some of the identifiers requested were rejected")
     (subproblems ((urn:ietf:params:acme:error:malformed
                    (detail     "Invalid underscore in DNS name \"_example.org\"")
                    (identifier (dns _example.org)))
                   (urn:ietf:params:acme:error:rejectedIdentifier
                    (detail     "This CA will not issue for \"example.net\"")
                    (identifier (dns example.net))))))

but, i would also argue that the two examples are not equivalent. what is explicitly specified as "type" and "value" in the json data, is implied in the s-expression data. either format is fine, but it would be better to compare like for like:

an s-expression equivalent for the json example would look like this:

    ((type   urn:ietf:params:acme:error:malformed)
     (detail "Some of the identifiers requested were rejected)
     (subproblems 
       ((type   urn:ietf:params:acme:error:malformed)
        (detail "Invalid underscore in DNS name \"_example.org\"")
        (identifier
          (type  dns)
          (value _example.org)))
       ((type   urn:ietf:params:acme:error:rejectedIdentifier)
        (detail "This CA will not issue for \"example.net\"")
        (identifier
          (type  dns)
          (value example.net)))))

    {
      "urn:ietf:params:acme:error:malformed":
      {
        "detail":     "Some of the identifiers requested were rejected",
        "subproblems": 
        [
          "urn:ietf:params:acme:error:malformed":
          {
            "detail":     "Invalid underscore in DNS name \"_example.org\"",
            "identifier": 
            {
              "dns": "_example.org"
            }
          },
          "urn:ietf:params:acme:error:rejectedIdentifier"            
          {
            "detail":     "This CA will not issue for \"example.net\"",
            "identifier":
            {
              "dns": "example.net"
            }
          }
        ]
      }
    }

    {"urn:ietf:params:acme:error:malformed": {
      "detail":     "Some of the identifiers requested were rejected",
      "subproblems": [
        "urn:ietf:params:acme:error:malformed": {
          "detail":     "Invalid underscore in DNS name \"_example.org\"",
          "identifier": {
            "dns": "_example.org" }},
        "urn:ietf:params:acme:error:rejectedIdentifier": {
          "detail":     "This CA will not issue for \"example.net\"",
          "identifier": {
            "dns": "example.net" }}]}}

because if we spread out the s-expression example:

    (urn:ietf:params:acme:error:malformed
      (detail      "Some of the identifiers requested were rejected")
      (subproblems
        ((urn:ietf:params:acme:error:malformed
           (detail     "Invalid underscore in DNS name \"_example.org\"")
           (identifier 
             (dns _example.org)
           )
         )
         (urn:ietf:params:acme:error:rejectedIdentifier
           (detail     "This CA will not issue for \"example.net\"")
           (identifier
             (dns example.net)
           )
         )
        )
      )
    )