Basically, it's because we expect markup to have meaning. The situation is pretty different from what it was with a traditional GUI builders because of the markup hiding back there.
In the bad old days, Dreamweaver had visual tools for this stuff, and it generated a horrifying mess of nested tables. This was rightly criticized because it made for a huge amount of markup, the markup was difficult to embed in a generator, there were lots of ways to destroy the layout if the content you inserted into it was the wrong size or had the wrong stuff inside it, and it was hell for web scrapers and screen readers. The generated page had no semantics and tripped up all these secondary uses. It also tended to be huge, slow to load, and hard to edit later.
Once CSS grew more powerful, a big fight ensued for semantic markup: keeping the template semantically meaningful (no tables of images and lack of table content), easy to generate and fill and easy for scrapers and screen readers, and doing all the layout in CSS. The mantra became something about hand-coded HTML always being better than machine-generated.
It probably could be done better today (and with the prevalence of JSON APIs semantic markup may not matter as much as it used to), but once the philosophy becomes widespread it becomes difficult to unseat. When you have developers who are competent at CSS and semantic markup, the sales pitch of moving back to a visual editor becomes harder.
No, we don't "expect (HTML) markup to have meaning". Browsers don't do anything with that semantic information. What we have are generators which use HTML/CSS as an output medium, like Postscript or PDF.
Sites with HTML tables were faster to load, smaller, resized automatically, and never had overlapping text. Most of the claimed benefits of CSS were false. CSS pages tend to pull in, or include, large libraries of styles, Javascript, and other junk. That's where page bloat comes from. See yesterday's article on why the web is so slow despite more bandwidth. Do "view source" on the pages of some major sites. It's disgusting.
There seems to be a programmer mindset that users must write source code which is then compiled to something else. Nroff/Troff, then TeX, then DocBook, for example. (Is DocBook dead? The last update on the DocBook site was three years ago.)[1] This is a terrible thing to impose on users.
You're confusing cause and effect. There was a movement that posited semantic markup would be good, and we all (mostly) accepted it. CSS's technical shortcomings were very pronounced in the beginning and mostly abated soon after. Achieving the perfect 3-column layout was still hard, as was really centering something, but most other stuff wasn't that far out of reach.
Now there are new problems having to do with bloat, and of course many people use Bootstrap wrongly, but nobody is honestly suggesting you go back to table-driven layout. I'm saying, this is the philosophy that got us here. I'm not saying it works well or that most content is semantically tagged—it isn't.
Your concluding remarks also seem off-base to me. TeX to some extent and LaTeX to a much greater extent put a lot of emphasis on semantic markup. It's just locked up in TeX-land and hard to parse outside of it, so the utility is limited, but every edition of the TeXbook and Guide to LaTeX2e expends great effort encouraging you to introduce semantic macros into your documents so that changing the style does not require extensive rework, as it would a Word document without stylesheets. Even the old Nroff/Troff macros had semantic-ish macros you were supposed to use. And DocBook really could not be further in this direction, where all the styling happens in CSS or XSL, and you have tags like `<computeroutput>` and `<funcprototype>`. I don't see how semantic meaning is an imposition, and anyway, the document authors and the document readers are not the same people.
I remember dreamweaver, and I have the mental scars to show from using it. However, dreamweaver came about in the time of table-based layout and refused to adapt when the market consensus moved to div- (and later semantic element-) based layouts.
There's no reason that I can see, that you wouldn't be able to name the elements in a document (or ML could be perhaps used to auto-derive names), and beyond that, my understanding is that semantic markup (at least in terms of class/ID names) hasn't proven to be all that important since the advent of the API. Perhaps it's just not been done well enough so far to justify moving over from HTML/CSS, but you'd expect people to be jumping to solve their own issues. I for one find CSS/HTML tweaking to be pretty monotonous when I'm just trying to get to an end result.
I agree. I think the situation created the philosophy which we have today, but the situation has changed. It probably could be done better today, just either nobody's doing it, or it's not gained traction yet.
In the bad old days, Dreamweaver had visual tools for this stuff, and it generated a horrifying mess of nested tables. This was rightly criticized because it made for a huge amount of markup, the markup was difficult to embed in a generator, there were lots of ways to destroy the layout if the content you inserted into it was the wrong size or had the wrong stuff inside it, and it was hell for web scrapers and screen readers. The generated page had no semantics and tripped up all these secondary uses. It also tended to be huge, slow to load, and hard to edit later.
Once CSS grew more powerful, a big fight ensued for semantic markup: keeping the template semantically meaningful (no tables of images and lack of table content), easy to generate and fill and easy for scrapers and screen readers, and doing all the layout in CSS. The mantra became something about hand-coded HTML always being better than machine-generated.
It probably could be done better today (and with the prevalence of JSON APIs semantic markup may not matter as much as it used to), but once the philosophy becomes widespread it becomes difficult to unseat. When you have developers who are competent at CSS and semantic markup, the sales pitch of moving back to a visual editor becomes harder.