(I haven't read all responses, yet, so if this reflects what someone else has already said, my apologies)
Not to mention that a certain browser has removed the selection for disabling JavaScript from the user interface, forcing said user to go into "about:config" to do it.
V/r,
^_^
Blame employers. They are too quick to add all of these flashy buzzwords for new technologies and JS-based frameworks to their job reqs so all of us engineers are in a constant mad scramble to learn these new buzzwords. And since there's no better way to learn than by doing we try to work them into our current projects be they personal or professional so we have some tangible learning and also proof that we've done that and have it in our portfolios. If employers weren't tossing the new technology buzzwords around (even though 90% of the time I've interviewed for such positions they are only interested in the framework, not actually using it) I think a lot more developers and engineers would feel less impetus to shoehorn these flashy new boondoggles into sites they're working on.
That being said, I'm in the industry myself and I feel and understand the pressure. I have built entire sites using client-side hydration with "single page view" loaded with XHS requests for everything and complex client-side data management just because I needed to have doing that in my portfolio. There was absolutely no need in the project to do it that way but I wanted to show off some Angular chops and that was a quick and dirty way to get some experience and toss something in my portfolio.
None of these new technologies are really radical or difficult to pick up and use (that's the whole point of them), so I think it's really unrealistic that employers absolutely grill job candidates on these things. If you're a solid full-stack coder or even a solid client-side developer and can prove you understand the basics then all of these frameworks just become convenience extensions in the right case at the right time. Employers need to keep that in mind, I think. They need to relax the artificial demand for industry buzzwords which puts us developers in a panic to prove we know the latest and greatest boondoggle of the month.
Can't just blame them. I've worked in enough shops that the developers pushed for new technology just because they wanted to play in the new toys.
One shop went from .net to php running Symfony and interfacing with Drupal simply because one (and only one) developer wanted to play with them. Didn't matter that no one had any experience working with php, Symfony or Drupal. And we were in a ridiculously small timeframe without well defined requirements. Needless to say, it wasn't fun.....
You can just use a simple extension for that too. 
https://chrome.google.com/webstore/detail/quick-javascript-switcher/geddoclleiomckbhadiaipdggiiccfje
https://github.com/maximelebreton/quick-javascript-switcher
Crikey this thread grows quickly!
Can I just point out: Progressive Enhancement is NOT about whether users have JavaScript switched off. It's about getting sites/apps to work on every device. The web is device agnostic and, with PE, your site can be used in Chrome 42, Microsoft Edge, IE1, Lynx, Opera Mini, the Google indexing bot, screen readers, ebook readers etc. As long as the device can download HTML, it'll work. That is a good thing.
PE doesn't mean functionality and effects are removed or simplified. It means you add them for browsers with support. And it's not significant additional work of you do it right from the start. The only people saying PE is too much effort are those who don't do it.
Perhaps you don't care about wide coverage? Perhaps you expect your app to die within a matter of years? Fine: develop using a client-side framework and slap a "best viewed in Chrome" logo on the front. But be aware you're developing using web technologies: you're not developing for the web. You're blocking a section of the community. That could be search engines. That could be potential buyers. That could be those with motor or visual imparements. There may be legality, profitibility or future-proofability(?!) consequences.
To me though, it's just about doing the right thing. You shouldn't care about who's using your site or what device they're using. Everyone is welcome.
I agree with everything you're saying there, about Progressive Enhancement, and device agnosticism (to a point - we can't help it if people create really stupid browsers that are overly limited in capabilities, or insist on using browsers that are, then they may get the inferior experience and complain; but that's not the developer's fault, as at least it works).
However, I still feel like there are cases where considering support for IE1 or Netscape or the Internet Browser on my Kindle Paperwhite or whatever the crap we're discussing are just... irrelevant. I'm sorry if that's a point of contention, but... that's just how it is. If people choose to make what are basically ridiculous decisions about what they use to browse the Internet, then I guess they'll be frustrated.
You shouldn't care about who's using your site or what device they're using. Everyone is welcome.
That is simply not true. There are countless web applications designed for particular groups which are not welcoming everyone. I'll point you, to start with, to a company intranet.
Everyone is not welcome and it's in a very software controlled environment, in some cases, to boot.
Now, do I think it should work on multiple browsers? For sure. I 100% agree with that. But is your actual argument valid here? No.
And you definitely should care. Having information and using it to make informed decisions isn't bad; it's good. And the general idea that we shouldn't care who's using a site is even more crazy! Have you ever heard of marketing at all?
TL;DR - I like the idea of PE in general. I love the idea of it for use on much of the web. But I don't find a need for it across the board, and I find the idea that we shouldn't care who uses our apps to be absurd.
The proliferation of client side JavaScript frameworks puts you in the minority along with the rest of the "old timers".
I think the problem (if it's right to call it a problem) is that web applications are getting closer to looking and behaving like desktop applications, and desktop-like applications don't decompose well into static pages. It takes more work on the server-side because you'll need to create page views that only the non-JavaScripters will need. And it takes more work on the client-side because we don't even have static content to enhance anymore; we have templates from which we generate dynamic content.
If we happen to be building a more traditional kind of website, then certainly use PE. But if we're building a desktop-like application, then sometimes we just have to accept that JavaScript is required for the thing to work.
That's not entirely true. First thing that comes to mind are the fact that CSS :hover doesn't work in IE6 and some of the older mobile browsers have problems with persisting them.
Do you use CSS3 or HTML5? If this is truly the case and you try to make things as agnostic as possible, I don't think JavaScript should even be a consideration. If you want to get into compatibility problems, then JavaScript has been used historically for 2 things: 1) Tacky Effects 2) Fixing Compatibility & Display issues across browsers, devices, and screens.
It may work. But if it's an app, the user probably won't know how to use it without CSS or JavaScript. I can't speak for anyone else, but I've always been in favor of content based sites not to be reliant on anything but the HTML.
Actually, I build for the opposite. I don't see what developing in a client side framework has to do with that. Backwards compatibility is going to be around for at least as long as support and it's a heck of a lot easier to support apps built under old outdated frameworks, than it is trying to figure out what that specific developer decided to do. If you're not pulling off a CDN, which you can't do if you build for longevity, then it doesn't matter what happens in 5, 10, 15 years as long as you have minimal support.
Of course they won't get the same experience. But neither will those using screen readers. Are you saying they should be abandoned just because their technology is old or different to yours?
An Intranet is not the web. It's closed. Use whatever you like. That said, I would make the point most large corporations use browsers such as IE6/7/8. PE will prevent you going mad in those environments!
I totally agree that some apps need JS. Consider Google Maps: it's impractical to build a server-only version (although Google has a separate application to do it). But those applications are relatively rare.
CSS is a great example of PE! So :hover doesn't work in old browsers. Why is that a problem? If you're relying on it for something such as a menu there are plenty of ways to get around it.
Posssibly but it seems we haven't learned from history. I thought the bad old days of "best viewed with..." were over but it's happening again.
I think that's the main issue here. When does a web system become an 'app' for which JS is essential? When you have a hammer, everything looks like a nail.
I know this is a minor point, but that's not really correct. Hover always worked in IE6, it just had a few edge-case bugs, as I describe in one of my really old articles on Smashing Mag. But that is kind of beside the point, so I'm just being a nitpicky troll.
He actually had IE6 dropdowns as his example. I told him that they actually ARE possible (CSS only, yes!), just not in the conventional way.
He then edited his post. He forgot to mention it's not readily available on most elements, but it does work.
Of course they won't get the same experience. But neither will those using screen readers. Are you saying they should be abandoned just because their technology is old or different to yours?
That depends, as I feel like I continue saying to people who can't seem to understand, on the application! For informational websites? I think it'd be frustrating to not be screen reader capable, or to have content at least available in text format, even if the UI is butchered. For many interactive applications, though, they're essentially built as visual things that can't be effectively reproduced with screen readers at all. You can't simply run around making generalizations about what people have to or should do without looking at their use case.
An Intranet is not the web. It's closed. Use whatever you like. That said, I would make the point most large corporations use browsers such as IE6/7/8. PE will prevent you going mad in those environments!
What makes an application a closed environment and not "the web" according to you? What if my example is an extranet? How about any application within which the majority of the content requires you to be signed in? Facebook? The task manager I use? Google apps? Are those things not built using web technologies, by web developers, and part of the web, by your definition? They could all, in theory,have particular requirements depending on what their application does (those are random examples of the countless ones, please see the broader picture) and particular markets / user statistics that make them support or not support some thing or another, or require some technology or another.
Posssibly but it seems we haven't learned from history. I thought the bad old days of "best viewed with..." were over but it's happening again.
For what it's worth, I use a combination of the latest Chrome, FF, and IE11, primarily Chrome, and I have literally never that I can recall run into a situation where a site/app that I used was requiring one particular browser - excepting old corporate crap that required ActiveX and IE only. Maybe the best solution for browser choices here is simply "keep with the times".
I think that's the main issue here. When does a web system become an 'app' for which JS is essential?
Excellent question.
ok lol... that's pretty confusing. Anyhow, like I said, it was kind of beside the point and I haven't read this entire thread, it's gotten really long!
that's pretty confusing
it was kind of beside the point
it's gotten really long
All sentiments that describe most of this thread, in one way or another 
Exactly! That's an excellent argument for using PE and writing device-agnostic code!
You said it was an intranet? You'd know every user and what devices/browsers they're using. That's not the case for public services even if they're behind a login.
Great! Let's use pointer events: it has good cross-browser support. Except for Safari. But who cares - that's only used by 5% of the desktop market and Apple should "keep with the times"!
The point is that PE allows you to use modern technologies without waiting for others to catch up. Why is that a problem?
If you develop for a subset of browsers, only people with those browsers will use your site. Those who can't use it will disappear from your audience and statistics. They rarely complain - they just go elsewhere.
PE allows you to develop for the web - not browsers. Developing for browsers is a bad idea. Ask IE6.
Exactly! That's an excellent argument for using PE and writing device-agnostic code!
Taking partial quotes and out of context to boot doesn't make you cute 
You said it was an intranet? You'd know every user and what devices/browsers they're using. That's not the case for public services even if they're behind a login.
I did, as an example. And I definitely know that all intranets are not that closed - so that you'd know every user and device. And you didn't answer the question - I'm asking what you consider part of the web, and what you consider to be needing to follow your principles?
Great! Let's use pointer events: it has good cross-browser support. Except for Safari. But who cares - that's only used by 5% of the desktop market and Apple should "keep with the times"!
The point is that PE allows you to use modern technologies without waiting for others to catch up. Why is that a problem?
It's not a problem at all, in some cases! Maybe even most cases, I don't know; but in every case I believe that the developers/owners have the right, and the freedom, to do whatever is correct for their application. It doesn't really matter what you think, or their users think, even - if their users dislike the service, then they'll go elsewhere 
I personally might steer away from things that 5% of the market can't use; Jane Doe developer down the road might disagree, and think that that 5% wasn't relevant to her app. Who am I to judge her for that decision? She knows her clients, app, and stats better than I do!
If you develop for a subset of browsers, only people with those browsers will use your site. Those who can't use it will disappear from your audience and statistics. They rarely complain - they just go elsewhere.
And if that's not a problem for you, then fine! If it is... then do something about it. I don't see why this is a contentious point.
PE allows you to develop for the web - not browsers. Developing for browsers is a bad idea. Ask IE6.
IE6? Is that an argument of some kind?
https://www.modern.ie/en-us/ie6countdown
PE is a fine idea sometimes, especially when dealing with static, informational content; and maybe some of its ideals can be employed in more complex applications, but as a standard across all of them? It just doesn't make the same sense to me as it does to you.
When it's not content based or requires user input/interaction.
You could tear that statement if you wanted to, but it's a pretty clear distinction if you're not being pedantic. Facebook, Soundcloud, Discourse, Netflix, Reddit, etc. are all apps. They are all heavily reliant on user input, user interaction, and usability. Wired, Sitepoint (the site), Medium, MSDN, or your local Mexican Restaurant site are not apps. They are sites.
Basically if it's not an article/blog, a reference, or a business's "web presence"... it's probably an "app". However, all could probably be enhanced by JavaScript, I'd say working without it is just as important. Now... the CMS that's probably used to fill the content of those sites is definitely an app.
Of course you have the right to develop web applications however you like (legal obligations permitting). Use table layouts. Use spacer GIFs. Use ActiveX. Use JS-only sites.
But I don't see why that's an argument against PE?
You think it's not? The reason IE6 hung around so long was not the (total) fault of Microsoft or systems administrators. It was because developers wrote code which worked in one browser. While the situation isn't quite so bad now, it's happening again: developers are targeting three or four modern browsers. We never learn.
It's not quite so clear-cut. Does adding a search and contact form make your web site into an app? More specifically, does adding a few forms become a justification for using a JS framework?
I'm not saying you should never use Angular/whatever. But to shun PE as a technique or suggesting it's a bad practice (#46) in all situations is nonsense.
I think that it's because PE smells like it's hard work, where you have to personally do all of the development.
Is it possible for any given framework to supply PE as a natural part of their support? In many cases it can be, for example, this Javascript Micro Frameworks and Progressive Enhancement article uses Backbone to create the TODO app and shows how PE can be maintained throughout the process.
It does take extra work, but that is the cost of anything that's well crafted.
It can also be argued that when you support the 1%-2% of visitors that don't support JavaScript, that they will keep on coming back to you time and time again purely because you are one of the few that they can access.
