I think the real point here—the one that half the article was spent in making—is that Lisp (the grammar that uses lots of parentheses)
isn't the same as Lisp (the concept).
Lisp (the concept) isn't a language at all, as far as we use the term to describe something that humans can use to communicate information serially. Lisp is actually a model for representing a transformation of an AST as an AST—no more, and no less. To communicate a Lisp transformation model, we must encode it as a stream of characters—and that stream, if we don't do anything to make it readable, becomes the "degenerate case" of programming languages: pure S-expression syntax.
However, there's no need for Lisp and S-expressions to go hand-in-hand. For decades we've known that programming languages have UX considerations every bit as important as those of the programs made with them. Lisp precedes that realization, but even when Lisp was first invented, S-expressions were never intended to be its primary encoding (search "M-expressions".) It just turned out that Lisp was such a powerful model that it was immediately put to use before a nicer syntax could be wrapped around it. (Also, its core user-base were mathematicians, who already had the isomorphic Lambda-calculus notation to think in terms of, so the learning curve wasn't evident to them.)
The point I'm getting at, here, is that any programming language syntax can have Lisp-transformation-model semantics. As long as `read` and `eval` are separate functions of your compiler+runtime, and the AST that normally travels between the two can be manipulated by your own code, you have a Lisp.
That's what people mean when they say that "the parentheses don't matter."