I somewhat regret starting this discussion here and apologise for accidentally hijacking the thread.
IMO, your last statement, "it suddenly becomes decent language (at least for frontend)" is key - yes, if you are just doing inversion of control, and just wiring simple actions off elements, then JS is fine. As soon as you start doing anything heavier, it becomes horrific. However, it's not clear to me where the problems are JS's own fault and where they're library/implementation issues. For example, the CPS mess that results due to a lack of threading: as soon as you start doing any real IO, any semblance of control flow you thought you had has rendered your code to a mess of spaghetti. But the ECMAScript 5 spec is, IIRC, silent on the issue of threading and IO in general. The many definitions of bottom (false, undefined, null), the endless variations of implementations, the endless duck typing and random heuristics and general lack of any degree of confidence that different libs will actually work together - there is no static way of validating that one library will not do things that are thoroughly incompatible with other libraries. NodeJS certainly exacerbates these problems to the Nth degree, but they're there in the browser too.
The issue about learning the language "properly" is that it's difficult to when certain aspects of the language (e.g. the "new" operator) were put there deliberately to "lower the learning curve" but serve merely to confuse. As you say, if you know what to stay away from then it perfectly fine, but then the same is said of Perl. And complex Perl might actually be more readable than complex JS! Once you have learnt the language properly, you realise how significant the lack of sensible language features really is; the threading issues in particular. Promises and friends help to a degree, but really you just can't write large maintainable code bases that do anything particularly complex. Now if you thus treat JS as a DSL for the browser, that might be ok, provided you don't try and do anything too complex in the browser (though the C-like webGL is clearly complex from the exact opposite end of the spectrum!). But firstly people want to do more and more in the browser, and secondly, JS keeps being used as a more general purpose language outside of the browser, which just strikes me as odd.
HTML is fine as a document structuring DSL when you actually get to use it for that, but most new single-page-apps start with a blank HTML file just loading scripts, and all DOM elements are constructed programmatically from the JS. Programmatic construction of GUIs is (IMO) a poor idea at best because it tends to put off anyone with any actual design skills from being involved. Graphical design of GUIs makes a whole lot more sense, at least to me, though I'm aware this is another can of worms that I don't really want to open! I remember in the 1990s writing applications under RISC OS. The graphical GUI designer, !WinEd (http://www.riscos.info/index.php/WinEd) was superb and I have not worked with anything that makes GUI design so intuitive and simple since (having done bits or more from ncurses, Java Swing/AWT and Java SWT, and HTML/CSS/JS amongst others).