Basically, if you are thinking your browser is a "platform", or you are thinking "the web" is "a platform" in the traditional programming sense, as the OP obvious is, then you are an idiot.
No, actually, he's quite right. It's a different method of programming, a different paradigm altogether. He didn't talk about programming the browser so that part of your statement is irrelevant, but as a design platform the web truly is different. At least before people tried to change a markup language into a full page layout and presentation language.
The problem with web applications - and the intrinsic problem of abstraction of the complexity that's solved by historical runtime environments that the OP likes, is that the render is independent. The whole article the other day about the Google device lab:
Completely and totally underscores the fact that markup and rendering are separate from each other, and that the system doing the markup has to understand, and either have variant code that it outputs so that it renders the same in as many browsers as possible -- or you need an entire device lab, because you've given up on solving the problem, and are willing to employ someone other than a "Normal Human" (per the current article) in order to chip away on a per device basis, until you exhaustively cover all possibilities.
The separation on the render is the problem with the web, as a platform, and it's why it's * not* "a platform", it's "N back ends * M browsers" number of platforms.
This separation is the same mistake that was made when window management was separated from X windows, such that you didn't get the same look and feel on all applications based on having a particular X Terminal/X Server on which the render took place. In other words, the primitives were too primitive, and you ended up drawing boxes and lines and patterns, instead of "pop up menus" and "menu bards" and "dialog boxes".
What the OP in this article is bemoaning as being missing is a self-enforcing emergent property of the design decision to separate rendering from markup, and to separate markup from UI logic, and separate business logic from everything else. It's why web services are so complicated, and why they are so fragile.
The only thing that ever came close to dealing with the issue overall, at a high level, was WebObjects, and even then, it didn't try to do it in a way that was renderer/backend/middleware/security model/web server agnostic.
So again, I'm going to say that web services isn't a *platform* in the traditional sense of a computer running one of half a dozen 80x24 block mode terminals to front end a COBOL program was a platform, and that anyone who thinks it is ... is an idiot. At best, they are engaging in wishful thinking, if they think Microsoft, Oracle, IBM, and other vendors of these things are going to settle on a common programming paradigm, and turn themselves into commodities, which would result in about 1/6th the revenue they're getting today.