Because canonical S-expressions don’t have numbers, just atoms (i.e., byte sequences) and lists. It is up to the using code to interpret "34" as the string "34" or the number 34 or the number 13,108 or the number 13,363, which is part of the protocol being used. In most instances, the byte sequence is probably a decimal number.

Now, S-expressions as used for programming languages such as Lisp do have numbers, but again Lisp has bignums. As for parsers of Lisp S-expressions written in other languages: if they want to comply with the standard, they need to support bignums.

You can write JSON that exclusively uses strings, so this is not really relevant. Sure, maybe it can be considered an advantage that s-expressions force you to do that, though it can also be seen just as easily as a disadvantage. It certainly hurts readability of the format, which is not a 0-cost thing. This is also why all Lisps use more than plain sexps to represent their code: having different syntax for different types helps.

"it can do one of 4 things" sounds very much like the pre-existing issue with JSON

> Because canonical S-expressions don’t have numbers, just atoms (i.e., byte sequences) and lists.

If types other than string and a list bother you, why don't you stick with those types in JSON?