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))))))

the alignment of the values makes them easier to pick out and gives a visual structure

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)))))

or the reverse, a json equivalent for 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"
            }
          }
        ]
      }
    }

a lot of the readability depends on the formatting. we could format the json example more dense:

    {"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" }}]}}

doing that shows that the main problem that makes json harder to read is the quotes around strings.

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)
           )
         )
        )
      )
    )

that doesn't add much to the readability. since, again, the primary win in readability comes from removing the quotes.