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.
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.