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