The fundamental problem with S-expressions is that they are intended for (1950s) machine readability and human ergonomics takes a back seat.
This is, of course, mostly a matter of opinion and experience, but I find S-expressions highly readable and LISP syntax superior in readability to every other syntax I've seen, as long as different parentheses are allowed like in all modern LISP dialects.
There are two other problems with LISP. First, it's so powerful that the semantics gets too rich, every author creates a DSL of its own with tons of macros and functions for every data structure. That makes code unreadable and difficult to maintain in the long run. At some point, every LISP program starts to look like a hack and you start spending most of your time transforming one data structure to another to interface with various packages.
The second problem is the focus on dynamic typing. I've found strictly static compilation better for debugging. Racket is particularly bad in that respect, as it tends to use ad hoc symbols with contracts everywhere. Static enumeration types are just way better for that purpose. Ideally, they should even be tied to the functions they are used in (e.g. a "function parameter type" with appropriate scoping).
These are the main drawbacks of LISP, maintainability and readability of code written by others is too low, because of a tendency to encourage hacks and DSLs.
If I can get one thing, I'd probably say practice in immutability. This simplifies a lot of things, even in java. In Clojure, immutability is first-class.
<DashboardUnit data-index="2">
<h1>Scores</h1>
<Scoreboard className="results" scores={gameScores} />
</DashboardUnit>;
[dashboard-unit {:data-index 2}
[:h1 "Scores"]
[scoreboard {:class-name "results"
:scores game-scores]]
Disregarding that, and in my opinion, properly formatted JSX might be a bit worse then s-expr for shorter stretches of code, but if/when you have a longer stretch, the visual symmetry in JSX would seem to tip the scale the other way. If there is a point to JSX, I would claim it's mostly that it looks different than the surrounding code that is the point, as it potentially makes it easier to parse and to clearly separate roles between code and design.
While I'm frankly not a fan of either of the above-mentioned, I do find some of the arguments around the brilliance of s-expr to be perplexing. The most confusing argument is the one that s-expressions are good because everything looks the same, which to me sound like arguing that the best way to paint is to only use one color, which I vehemently disagree with.
I think the easiest explanation of this conundrum boils down to a rather simple fact. Visual regularity is as confusing to some, as the lack of it is to others. People are different, sometimes shockingly so.
The point of the syntax isn't necessarily that everything looks the same, it's more around why that's the case and what other properties it enables. In other words, if a homogeneous (and arguably less convenient) syntax is the downside, it's important to consider the upside too. This still not make it 'better' enough for to want to use, but maybe will shed some light on why reasonable people might think differently.
The core concept behind Lisp syntax is that Lisp has a handful of core data structures, and the user syntax of the language is defined directly in terms of those structures. Clojure uses sequences, vectors, hashes to do things like represent blocks of code, argument lists, and type declarations. The structures used for this are the same as the structures uses in user code, and what you type in to the keyboard when you program are the normal textual serializations of these structures.
So this gives a couple of benefits:
1) The character sequences used to represent the language are easy to parse in a structural way without a whole bunch of parsing logic. A structural editor for Lisp doesn't necessarily need as complete a grammar or parser to enable the structural features as does a language like Java, Scala, C, etc.
2) It's easier to generate or manipulate code. Most famously, this enables things like macros. Macros and code transformations are absolutely possible in languages like Java and the JS ecosystem, but less commonly used and more expensive to develop.
There are many other examples of where these properties come in handy, but JSX turns out to be a reasonable illustration of why these are useful. Adding something like JSX to Javascript requires an explicit preprocessing state. Then, it also requires specific editor support to deal with the modified syntax. Once all that's done, what you have is a wrapper around 'React.createElement'.
It says a lot about the value of application-specific syntax that people are willing to pay those costs to get a certain syntax, but the Clojure/Lisp approach (hiccup for markup) reduces the costs and makes that kind of thing significantly easier to do. Whether or not that's the tradeoff you choose to make is one thing, but there are reasons to make it.
I like the ideas behind clojure, I really do. I even wrote a non-trivial personal project with it. However, coming back to that code after two months was basically like the plot of Memento. I ended up rewriting it in JavaScript instead.
Some prefer semicolons and other "visual garbage" in their code, I like minimalism and structure.
No other language can retain readability on different screens like Clojure can. Even reading it in a narrow screen of a mobile phone - it would wrap, but still retain its readability. Good luck trying that with literally any other (non-lispy) language.
Comparing that to your 30 years practice of XML is not at all useful.
As to your other point - maybe. I'm not seeing anywhere near enough potential payoff to invest years into it, though. Also, I'd argue that makes it a terribly impractical language if you're interested in getting work done.
To clarify, I don't agree one needs years to become competent in clojure. But if one did, that just makes it a worse value proposition.
Sure you can get things done and ignore the maintenance horror later.
Anyways, in the 30 years we at least steadily transfer features from Lisp.
This is not a snarky question, I'm genuinely curious since I personally have no problem coming back to old clojure code.
The other factors are cultural - so much of the clojure ecosystem is badly documented, or not at all. Sure, I can go and read your code to figure out what it does. But that comes back to the limited time argument, unless I'm paid for it, I'd rather write stuff in a language with a culture of proper documentation. For a recent example that does an outstanding job, see Elixir.
Finally, the ecosystem just feels... abandoned? Like walking through a ghost town. A lot of things on GitHub look incredible, but if there's no commits in the past 3 years I'm not inclined to invest time in it. I know the common argument about them being finished, and I don't buy it - non-trivial code rarely is.
The JSX looks immediately intelligible to me because I'm used to looking at HTML. The Clojure looks unfamiliar but it's not so strange that I can't imagine it feeling just as natural a way to represent the same data structure. It would just take a little while to get used to.
The major issue I suppose is that this example is supposed to render to XML, which is closer to JSX than Clojure. But by that standard Vue (or XSLT) is even closer.
I've done a little professional work in Clojure and wasn't a huge fan, but it didn't seem particularly bad (syntactically). It just seemed like something you had to get used to.
That's my point. It is simply "unfamiliar" to majority of developers who have never tried Lisps. And a lot of people throw baseless claims it to be "less readable" without even given it a try.
A few years ago plain English to me was "unreadable". But I have learned the language. And look, today I can even make comments on HN. I guess it's a good thing I haven't dismissed the language because I was unfamiliar with it.
My conclusion is that those languages which incorporate S-exps become identified as some kind of Lisp. This is the case even when it's a misidentification; i.e. little else is there of any Lisp "DNA" other than the parentheses.
Or else, those languages become identified as something that is not modern.
Thus, no modern, non-Lisp language has S-exps.