The particular subset of general S-expressions applicable here is composed of atoms, which are byte strings, and parentheses used to delimit lists or sub-lists.
There are other encodings in common use: Generally, csexp has a parser one or two decimal orders of magnitude smaller than that of either XML or ASN.1.
Thus, XML can be "configured" for particular kinds of data, which conform to some grammar (say, HTML, ATOM, SVG, MathML, or new ones as needed).
This is not surprising, since XML can be described as a differently-punctuated form for LISP-like S-expressions, or vice versa.
[1] However, XML includes additional semantics, which are commonly achieved in csexp by various conventions rather than as part of the language.
Similarly, csexp atoms are binary (consisting of a length prefix followed by totally arbitrary bytes), while XML is designed to be human-readable (while arguably less so than JSON or YAML) – so arbitrary bytes in XML must be encoded somehow (for example, a bitmapped image can be included using base64).
This means that storing large amounts of non-readable information in uncompressed XML takes more space; on the other hand, it will survive translation between alternate character sets (including transmission through network hosts that may apply differing character sets, line-end conventions, etc.).
Two different structures – each a SEQUENCE of two INTEGERS – have identical representations on the wire (barring special tag choices to distinguish them).
Once a wire-format expression has been parsed into an internal tree form (similar to XML's DOM), the consumer of that structure can examine it for conformance to what was expected.