I can't say i've ever read the opinion that LISP's syntax allows more expressive programming; rather LISP itself allows more expressive programming at the tradeoff of the syntax.
I can't say i've ever read the opinion that LISP's syntax allows more expressive programming; rather LISP itself allows more expressive programming at the tradeoff of the syntax.
When your syntax can be manipulated like data (in this case lists), macros become regular functions operating on regular data, the data just happens to be syntax in this case. I can take a struct definition for example and use regular, built-in list manipulation functions to walk the definition and transform it into whatever I want.
In something like Rust we can also run macros on struct definitions, but in that case you operate on a token stream, and need specialized libraries and functions to do meaningful transformations. It ends up being much more difficult but still pretty powerful.
Super powered macros is what makes lisp "lispy" to me and the "abnormal" syntax is required for that, so I do think the syntax is what makes is uniquely expressive.
The first attempt was Lisp 2. This doesn't refer to Lisp-2 (two namespaces for variables and functions) but to a follow-up to Lisp 1.5, which was tried in the 1960's. Lisp 2, IIRC, featured an Algol-like syntax, with types, for speeding up numeric processing. It went nowhere. In the early 1970's, Vaughan Pratt (of "Pratt parser" fame, I think) created CGOL. That also went nowhere. After that we can identify numerous other things in that vein.
Here we are today and most people using Lisp still have it (looking (like) this).
The conventional idea from LISPers is the other way around: LISP's syntax allows for more expressive programming, because code and data are isomorphic (so, macros and rewriting, etc.), and any function you make looks (and is, and behaves) as "first class" as any native one.
LISP's syntax is also said to be a better and more concise way than JSON (and or course XML) to describe arbitrary hierarchical structures.
A lot of the flexibility of lisp relies on there being no difference between a list of symbols and code (for, example, this is how the entire macro system works).
Function calls being inside the parentheses (and, really, all language constructs just being lists of symbols) is generally what people mean when they say the syntax throws people.
These two things are at odds.
You could go with Racket's method of letting people use alternate delimiters, but that's a fairly trivial reader macro in common lisp and probably not worth releasing a language over.
Best I've seen so far (outside of lisp) is elixir, but it really bogs down the entire thing by requiring a bunch of extra information and metadata that common lisp can infer by position and an extra layer of indirection.