Generally Lisp has two main goals:

* allow code to be data and data to be code

* make coding and coding code (let code manipulate code) interactive

The s-expression based syntax was found to be useful for both. For the latter it means that code can be manipulated interactively for example by structure editors or in read-eval-print-loops which work with data. That makes interactive code writing very ergonomic.

I think 'everything is unergonomic' is a too strong of a statement to be true.

I'd argue that lisp is very ergonomic for those who work with it regularly (and are into using Emacs). It sounds like you are beefing with the syntax (or lack thereof) and homoiconicity of Lisp. I can understand that. It is a very different language than others currently in the mainstream for that reason.

As far as overall ergonomics, I'd say the REPL/image-based development style and the macros that are enabled due to homoiconicity actually make it one of the most ergonomic languages in existence.

The biggest thing that prevents Lisp-likes from going mainstream is that it is too ergonomic, specifically, when you start reading a Lisp codebase, you essentially are signing up to learn a new project-specific dialect. Very ergonomic for writing code, but at the cost of understanding how that code operates.

That is simply false. The ergonomics of editing Lisp is also superb.

There is a consistent, logical way to break any Lisp expression into any number of lines of text. The more you break Lisp into multiple lines, the more clearly the tree structure of the code is revealed.

The absence of ambiguity helps readability: not having to guess which expressions are children of what operator.

Lisp code sometimes makes up for the parentheses by omitting superfluous punctuation like commas and semicolons. To add two terms, we need ( ) and +. But that's all we need to add 17 terms also.

Imagine if the Unix shell required commas between arguments:

  ls, -l, *.c

The more usual Lisps (I consider Julia, like Dylan before it, to be a Lisp) give up most of the advantages of syntax in exchange for an admittedly eloquent macro system. Julia gets the advantage of syntax, and a macro system which is of equal expressive power but less easy to use. Also, in Julia, a macro leads with `@`, the way a macro in Rust ends with `!`, meaning you can read the difference between a macro and a function at the call site. I consider that a good thing.