This is beginning to feel like a ritual HN ceremony!
That isn't to say, JS-based games aren't progressing. They are for sure. Most notably on a platform the article didn't mention-- facebook.
There's a huge amount of inertia to overcome - lots of people with old browsers unwilling to upgrade, old computers that simply can't run games, and incredibly broken configurations (whether due to bad browsers, bad plugins or bad drivers) where simple HTML5 audio/rendering can crash the browser or reboot the machine. When we first put it up we got lots of complaints and our average review was closer to 3 stars, despite doing tons of testing up-front; eventually by sorting through the issues one by one we got it to the 4 stars you see now. Despite this, Flash games of comparable quality get higher scores, more views, and more revenue (nobody is willing to pay to show ads in HTML5 games; for Flash games there are entire ad networks).
So I guess what I'm saying is that you're mostly right.
On the other hand, a few people I know who make a living off flash games have said that sponsorships are fewer and further between now, and that ad revenue is decreasing. I don't know whether this represents an overall decrease in the value of in-game ads, or whether Flash's reach is diminishing.
This talk was pretty enlightening: http://youtu.be/Ekz466sDprg
Also, consider Firefox and Chrome get updated every 6 weeks; that's around 500-700 million users getting fresh updates. Sure, "HTML5", that catch-all buzzword, needs a bit more work before it can match the current Flash, but it's pretty clear where people should be placing their bets.
When it comes to games I'd prefer just to manage everything within Steam or via desktop shortcuts, whether it is written in C++ , C# or JS is an irrelevant implementation detail for the player.
Of course by providing an installer for popular OSs that just fires up chrome in fullscreen mode could easily solve this problem.
Another (possible) issue is that most game devs like to keep their source private and include DRM. JS doesn't lend itself so well to that type of approach.
But the important things support the JVM.
JS in theory at least should be supported on anything with a relatively modern browser.
Well, anyways... I checked out the first game in the article's list of "great" HTML5 games (Contre Jour: http://www.contrejour.ie/#fbid=N0F1LHvfzzM). It was pretty good. Seemed to have relatively unique, interesting game mechanics, nice visuals, and I liked the music.
Article rang true for me, since it's exactly what I'm doing! Hyperlinks to areas of the game world, RESTful API for directly accessing the game world, client support from Android, etc. I also know of a few others doing similar work, so I think web gaming has a pretty bright future.
One of my favorite real examples is Scott Schiller's use of hyperlinks in his Survivor C64 game. He used hyperlinks to encode the entire level so you could then tweet the levels you create via short URLs and others could take that level, modify it and retweet it.
I'm curious if hyperlinks could even be used to create meta games. i.e. everyone makes different versions (equivalent to add-on packs) for a base game, where the hyperlink encodes the state of the current player and passes that state along to another level of the game created by another player.
Most MMORPGs don't know how to handle user input because users are basically trained as destructor bots rampaging the landscape by the game itself, and the designers haven't figured out how to move away from that. ATiTD moved away from it successfully.
Using URLs to link to in-game content is an interesting idea, something I'll play around with in the next few days and see about getting that as another feature of our API.
Persistent data on all devices is fantastic - of course, we need more HTML5 games that work well on each device. The two main issues I've seen developers run into with getting their games on mobile are 1) the performance in mobile web browsers (the latest Safari is pretty good, but most games still have a tough time) and 2) handling user input - developers are able to take full advantage of a keyboard on desktops and limiting to touch is a big change (though it seems a lot of devs forget about the accelerometer). If the developer has tackled those issues, we're here with the data storage feature of our API to allow for easy implementation of that idea. 
As for interacting with the DOM, it's funny you mention that, just yesterday we updated our homepage to have a mini-game in it (calling it a game is a bit of a stretch though) that interacts with the DOM .
The ability to seamlessly persist game state across devices is a powerful construct that really enables you to play everywhere. While being a simply useful mechanism, it also really helps users stay mentally engaged in the game experience if they can access it at any time. This fact builds upon itself if they can do so in small bite-sized chunks.
Additionally, the ease of acquisition of such games (we're using a DOM based approach, however, Canvas also applies here) is also a big win. We've seen our game gain tremendous traction in various offices where people wouldn't normally play games as you a) don't need to install anything and b) can play in 30 second intervals.
These two unique factors combined gives you a devious means to provide compelling game experiences regardless of where you and what type of computer you have access to.
A second question will be how can you make money from a game that can be easily copied ?
To deal with your game being easily copied you basically do what flash game devs do: basic rehosting protections (stops the laziest pirates), partnerships with advertisers, in app purchases/required server connections, etc.
In general, your assets are only protected by copyright.
"The Future of Games is the Web"
*And from his article, I interpret Web as Web Browser.
Assets are handled , sounds are handled and i dont need to test it on 4+ browsers to see if it works. I get a dynamic strong typed langage, a drawing soft and an animation soft , which is all i need to develop complex games.
- Do i care about mobile ? i can release my game as an native iOs app or air packaged app for android, i get exposure through app stores and can use native device capabilites to enhance user experience.
So yep , it's proprietary , but i chose ease of dev , deployement and fast dev cycles over theorical open-ness and awesomeness.
Web browser compatibility is an issue; however it remains a development issue. Building separate applications for each platform brings in other issues, such as app store rules and visibility. Granted, this is a trade-off.
which ones? you're talking about appstore rules but phonegap purpose is for a js app to be deployed like a native app,out of the browser.
> visibility :
an app on the app store is more visible than any app on a web site on mobile. I have no exemple of any profitable html5 game , on the other hand there are plenty ( machinarium )exemples sucessfull of unity or flash games.
Things may be different in 5/10 years , but i code for now and with stable technologies.