HTML+CSS for publishing static, stand-alone documents isn't all that bad. It's terrible for making "applications", and it's terrible for composing more than one thing into a page (such as a header, footer, table of contents/menu).
I still think Adobe's idea[1] of flowing content through boxes (aka the "desktop publishing way") makes more sense than many of the other "augmentations" for CSS in terms of allowing complex layout. But it is an idea that makes sense for basically composing pages - not really for "applications".
I'm not convinced there's much of a meaningful overlap between layout for hypermedia meant to be read/watched/consumed - and "smart object graphs"/"applications" that are meant to be interacted with. Other than that the latter can be used to build the former -- but that's a terrible way to approach standardization -- just for the problems related to accessibility and machine readability alone.
If we could agree to keep the two things separate, make some real effort into making better readers for better (but probably dumber/less feature-full mark-up) -- we would probably be better off. Even such things as readability[2] shows the merit of this: it shows, by existing, the virtue of a browser that is better at being a hypertext browser is useful (and that a browser that's better at being an application run-time can be used to build and host a browser that's better at being a hypertext browser...).
But I don't think we should need for users to relate to that many layers: an OS and standard library that acts as platform for applications, an application that acts as a platform for applications and an application in the form of html+js+css+possibly some server side magic that acts as an application for browsing hypertext. I'd very much like an application (a browser) that's actually good at just browsing hypertext too.
[1] https://www.adobe.com/inspire/2014/01/complex-layouts-reflow... (Now dead AFAIK, even though there's a js polyfill)