I've always though of HTML as a way to hide the idea that it the markup is just an s-expression shared over a network. Indeed, Roy Fielding's work on ReST leverages the default paradigm of distributed computing using immutable data-structures in the first place.
"I've always though of HTML as a way to hide the idea that it the markup is just an s-expression"
This is a historical issue with HTML. It's supposed to be "markup". The original idea was that HTML documents would be mostly text with some tagging. Since it was just "markup", markers that triggered formatting operations, it wasn't considered necessary that a strict tree structure be enforced. HTML5 still tolerates and parses such constructs as "Plain <b>Bold <i>Bold italic </b>Italic </i> Plain". This may be a holdover from the way things worked in UNIX nroff/troff, an early markup language.
XHTML requires that the tags balance, which seems to put a lot of people off. I thought at one time that XHTML would replace HTML, but that didn't happen.
In retrospect, browsers were made too lenient. It probably would have been better if, after detecting an error, browsers put a red band across the page with an error message, then continued to display using default fonts and colors. Then we could have avoided years of struggling with browser incompatibilities due to non-uniform handling of errors.
(I'm currently trying to figure out why BeautifulSoup 4, the Python library, creates a broken parse tree and crashes for documents which contain "<head><head> ... </head></head>". "kroger.com" has that. You'd think that the web pages of the Fortune 100 would be better.)
So much simpler to parse, so much less room for ambiguity.
No <b><i>mismatched</b></i> closing parens. No <p>optional close tags. No difference between compulsory close tags <script></script> or <img /> self closing tags.
But without a specialized editor, SGML is nicer to write.
SGML is nice for humans. S-exprs are nice for programs.
Easier to parse, but it would be close to impossible for humans to edit the real-world pages. Try turning any bootstrap template with their 10+ nested levels of tags into the syntax you propose, and then try moving things around in the editor, finding the right spot to append an element when all you see is something like )))))))), that would be crazy hard to do without errors. To make that work we would first need some kind of function syntax, so that deep nested blocks can be simplified.
Parent mentioned "specialized editor". What he meant was emacs + ParEdit, which alleviates these problems. With ParEdit, you don't navigate around and edit sequences of characters - you edit nodes in a tree - where each set of parens in the text represents a node and the individual identifiers are the leaves. It's awkward to use at first because you need to supress your usual text-editing habits, but the productivity gain once you're familiar with it is worth the training.
Besides, Lisp has the tooling for collapsing deeply nested structures into flatter ones if you need to, because one can use nested defines inside a function and later just call by name if needed. It just means the stuff that would've been more deeply nested will be defined earlier than it's container. Most of the time this is usually what you want anyway, because you're going to be reusing a lot of the structure elsewhere in the document - DRY becomes a lot simpler.
A lot of people get their start with HTML by just opening it up with .... whatever ... and fiddling with it. These people are not Lisp programmers, not by a long shot.
HTML is nice in part because it's pretty easy and accessible for people who are not programmers by training.
In a vacuum, they might be the same, although like someone else mentioned, with parens, you eventually get the dreaded ))))))) somewhere.
It's not in a vacuum though: there are tons of tools and tutorials and colleagues and other things dealing with HTML as it is, and tons of people used to how it currently is.
The original question, "how would sexprs make a better markup language", was in a vacuum. At least that's how I took it, and for good reason. A discussion whose pivotal argument is "well, that's how we do things now" is neither interesting nor (after the first few times your idealism is stomped on) is it illuminating.
In my experience, I've not found this to be true. When writing lisp, I find that very quickly the parens just disappear. Even when I first started writing it. And balancing tags in *ML languages is not something I've ever found "easier". Both require a specialized editors for "power users" to be more productive.
All pages would be about 1/2 the size the are now. Think of the gagillions of moogaboots we'd have saved over the years! These migibits could have been used to promote world peace or even disseminating your grandmother's unsurpassed oatmeal cookie recipe! You pick!
What's so different about:
<html> <head>...</head> <body> ... </body> </html>
and
(html (head ...) (body ...))
Wouldn't we've been better off with the latter anyway?