I've worked on projects where that was the expectation; I've set that expectation for projects.

The reasoning has both been concrete/practical and philosophical (but still practical):

* Mobile processing time is still costly in terms of battery life and performance. And the number of http calls (and their latency) also makes a difference in performance; SPAs tend to have smaller requests but larger numbers of them and it seems to me that's actually the opposite profile of what 3/4G cellular networks are good at. (And while this is all less true on the desktop I'm starting to find it annoying that we're nevertheless finding ways to make things choppy and slow on 2 GHz machines with operations not more complex than scrolling).

* This is more vague, but I find there's a discipline imposed in starting the conception of the app in terms of plain HTML/HTTP that seems to keep things better organized, while projects that start with a focus on a rich/heavy UI devolve into overspecific yet mixed concerns more quickly. This doesn't work for everything, since some apps just aren't about resources and media types. But honestly, your app probably is. :)

* Being able to debug/autotest with something like curl is pretty nice.

Nope. To me complaining that an app doesn't work with JS disabled is like complaining that the layout is busted with CSS disabled. It's not clear to me why I should worry about this case as a developer. You can turn shit off if you want to but don't complain that it doesn't work now.

I don't make that many web apps, mostly websites for clients, and I worry over IE8/9 users more than I do about people who turn their javascript off. It's a non-issue for us. If they have javascript turned off at such an aggressive level then they are used to things being broken all over the place.

I think it is not about web apps, more about the casual "one time visit" browsing. There is usually zero incentive to enable JS for a random website where you just want to read an article or watch images. JS there is usually (my impression) used for things that distract or try to lure me into other content. I like distraction free consumption. There is a high incentive to enable JS for a dynamic web app or site you regularly visit (eg HN) though.

Good control for JS and other requests in browsers makes this quite convenient to control as a (expert) user. I like umatrix a lot.

When I'm developing a website, if I have a time to do things the right way, I'm doing my best to present to user a usable website both without CSS and JS. Good semantic markup usually provides good user interface. And, as crawlers usually don't like JS, making non-JS version helps them to crawl the site anyway.

I browse with NoScript. Most sites are usable without JavaScript, maybe not as good looking but who cares. A few sites are not usable and I don't like them. If I really care about their content I enable some of their scripts. After a little, one gets good at recognizing the obvious candidates to enable and the obvious tracking scripts to keep disabled. This and that if I want to see videos (maybe I don't want), this and that if I want to hear audio, not that because it's the ad script, etc. If I don't really care, I go somewhere else. The same content is usually available elsewhere.

What would be better is the ability to selectively enable javascript scripts. I want the javascript for your webpage to run normally, but I don't want the javascript for that ad that moves around the screen or the one for that tracker bug to run at all. This was much easier when ads where mostly in flash.