Besides, I like you attitude. Making stuff work for everyone is a great and noble goal! Unfortunately, that's only worth your time if your goal is to learn, not to earn money.
Anyway, progressive enhancement kills all of the advantages of JavaScript application with the exclusion of more advanced UI features and simulated responsiveness. None the less, rather than reducing or evening the development cost burden with server side web development, it actually increased it because all of the server side development must be done and then a client side framework must be bolted on top of it. It is quite honestly the worst of both worlds because it spikes the complexity of the solution.
The numbers that we gathered in our research and post mortums of projects supports the conclusion that it is actually more cost effective to build two independent UI's one JavaScript UI and a reduced feature set server side based UI and route client to each according to capabilities.
Further, for many client the monetary outlay of developing the server side UI to support the < 1% client base that could not use a JavaScript UI was more than would ever be recouped for the investment.
In one of the analysis that we did it was actually cheaper to send the clients that did not have access to a supported JavaScript compatible browser a new machine than to spend the development effort to build out an independent system.
In all cases a better business case could be made for spending those development funds on alternative platforms like iPhone / Android / mobile client or IVR systems.
The segment of the market that cannot access JavaScript based applications is a very small segment and it is dwindling every day. For most web applications a business case cannot be made for progressive enhancement to chase this segment; especially when alternative platforms are added to the analysis. In almost all cases the time and money was better spent chasing those non-web segments for growth.
Please note this information is specifically related to web applications (web-based desktop application replacements) and not web sites like a news site. Web Apps are my companies specialty and we don't build web sites so none of this info should be construed as advice for article oriented web sites. Put simply, I do not know that these conclusions would hold true for building something like HN, they are true for building something like Salesforce.com.
Submissions go to another page, as do clicks and all that jazz. It's quicker for me to get the MVP up and running first, and then later add the JS niceties.
Obviously, there are use cases where this is flipped around -- mapping, for example, and I'm sure many others -- but at least for me, I don't understand why it's even a hardship to make it work for nonJS users, as that's what I always build first.
Workflow aside, you're probably right, at least for end users. Almost every device worth supporting out there is 'modern' enough that they support jQuery, Dojo, et al.
The real trick is of course the other important devices that aren't users. Search engines. Crawlers aren't necessarily capable of following your application flow without graceful degradation, and in this day and age, that likely matters as much or nearly as much as actual users.
