I've recently formed an opinion about why people keep wanting JavaScript, or perhaps I should say instead 'come to a realization'. Put simply, people want to increase the interactivity and responsiveness of their websites.

Let's rewind to the old days of basic HTML websites, which you have to admit are neither very interactive nor very responsive. You interact with such sites pretty much only by clicking on links (or form submission buttons) and they respond by giving you a new web page, which is usually both disruptive and not really fast; your browser window clears then fills in, things may shuffle around, your position on the page almost certainly changes even if the page looks more or less the same, and so on. This is workable but very limited and not particularly attractive; in many ways it goes against almost every tenet of good GUI design that we know.

(Part of the appeal of frames was that they were less disruptive this way because not all of the web page shuffled itself around when you clicked on links.)

Modern HTML and CSS improved this by adding support for a certain amount of standardized interactive behaviors and elements (eg you can now make pure HTML/CSS dropdown menus); because they're rendered in the browser as changes to page appearance they have basically instant responsiveness and don't require your browser to fetch a new page (with all that that implies). But this support can only go so far because in practice there is a fundamental conflict between simplicity and comprehensiveness (and thus flexibility) in specifying interactivity. The more options for interactivity you offer to people, the more complex the descriptions of those options need to be. Fully general interactivity requires a very general way to specify the logic involved, to describe what happens and when.

A very general specification of logic is called 'a programming language'. You cannot have general interactivity without a general language. The more restricted you make your language the less interactivity you can create. If you want as much interactivity as people can design, you need a general language. Hence, well, JavaScript.

(In this sense HTML plus CSS is a language, although an odd and rather restricted one.)

Note that this has nothing directly to do with browser vendors refusing to implement enough specifically hard-coded interactivity features in HTML and CSS. Even if they wanted to, they simply can't make HTML plus CSS powerful enough to cover the union of what everyone wants without turning it into a programming language. And a lot of language design experience suggests that doing so would actually suck badly (see, among other things, XSLT versus the programming language of your choice, and note that XSLT is Turing-complete).

(It also doesn't directly have to do with browser vendors not wanting to implement interactivity features at all. Implementing JavaScript plus all of its DOM and event hooks is implementing interactivity features, it's just not as visibly so as, say, new CSS properties. Implementing better JavaScript may also be a better use of limited browser engineering time because the browser developers can offload developing specific interactive behaviors to page designers.)

Now, you can have a vision of browsers as environments that should have deliberately limited interactivity and responsiveness and then argue from this vision that they should not support JavaScript and other ways of enabling 'too much' interactivity. There are even some reasonably rational arguments you can make for this position. However this argument is doomed to be very unpopular because people want to make pretty much everything more interactive and responsive (since that's a great way of improving the whole experience of using almost anything).

(This realization is undoubtedly obvious and well-trodden ground among the general web development community. I'm slow sometimes and I'm only an occasional tourist in this area.)

Sidebar: one potential rational argument against flexibility

The short version: common and unified interfaces. The more flexible you make interactivity, the more different websites can be from each other. You can argue that a great benefit of the browser over other interfaces is that everything has a common UI (especially in old school HTML) and that browsers should continue to act to enforce a relatively common interface by (among other things) limiting people's ability to create non-standard interactivity.

(Standard interactivity is offered through the browser's HTML and CSS, because the browser can control what you can do and how the result looks to give everything a uniform appearance and interface.)

If you want to make this argument you should be prepared to also argue against a number of current HTML and CSS design options because they do just as much damage to a common 'web UI' (if not more). For example, every CSS option that allows designers to confuse people about what is and isn't a link.

Sidebar: the purpose of CSS and HTML in this model

In this model, CSS (and HTML with it) has two purposes. The first is to be the rendering engine for the (JavaScript-based) interactivity logic. The second is to encapsulate sufficiently common patterns of interactivity into a form where you can express your intentions directly (and then the browser can execute them directly), much like how and why people add new functions to a standard library.

(As a consequence, if all you want is sufficiently common interactivity you can create it without needing JavaScript at all.)

My impression is that you can see both sorts of additions in modern CSS.

(I think I may have now horrified all of the designers who care about CSS. I've sort of horrified myself, honestly.)