I too believe the expectations of the vast majority demand AJAX. However, I feel like arguing the opposing view of the vocal minority
as an exercise to strengthen the argument.
If you have a "form" on a page and want to be able to work with it, without having the entire page reload, your ONLY option is JS. There are NO OTHER OPTIONS.
Of course there's another option: having the entire document reload, and redefining "entire document" to make it less painful. Make the form a separate document so that reloading the form doesn't reload everything else. This is how Slashdot's comment submission form worked before D2 was introduced, and how it still works if you open "Reply to This" in a new window, and how it still works in (say) stock phpBB. And people who prefer not to run non-free JavaScript (or any JavaScript at all) on their computers can still use it. And if static documents aren't interactive enough, implement a native application. For example, instead of a web-based forum like Slash or phpBB, put up an NNTP server to which any NNTP client can connect.
You simply cannot do 99% of what people expect in a "Web 2.0" experience
People who dislike JavaScript don't want a "Web 2.0" experience. They want a separation of applications and documents. They want HTML to be documents and EXE to be applications.
You're wishing to go back to a pure static page environment, or worse, a dynamic one where to do the SIMPLEST activity requires a GET or POST to a separate page requiring server side code to operate, create a dynamic page just for you, and then return it.
This is how Slashdot operated before D2, and there are apparently a lot of people who prefer how Slashdot operated before D2.
The only way to do anything again would be native code, thereby shutting out quite a bit of valuable innovation in the markets by startups that could have never afforded the resources for large coding shops that could keep track of code for multiple platforms.
A coding shop is supposed to first release a Windows application that has been tested in both Windows and Wine, and then use the money it earned by selling copies of the Windows version to hire developers to make a version for OS X. Or the other way around, if it's a Mac shop. Keeping the application logic (the "model") and presentation (the "view") separate makes it easier to maintain versions for both Windows/Linux and OS X. Or expose a network protocol that third-party native clients can use, such as NNTP or some REST-based API like Twitter and Amazon and eBay use.
The native code companies are cratering because they can't begin to hope to keep up with the SAAS companies using open source frameworks and rapid cross platform development to push out fixes and features in weeks instead of 3 years.
So why can't native code companies come up with frameworks to make native code development just as efficient?
Registering a CDN in the browser as servicing a particular domain
Who would be the authority for such registration?
Why would I host my own scripts AND pay the CDN?
Because historically, several CDNs have offered services only for static files, such as CSS, JavaScript, images, and video, not for dynamically generated HTML documents.