That's the thing though. Is my team really the exception? When you look at the highly immersive web that product managers and customers have come to expect, you simply can't build it without javascript. Once you've crossed that bridge, is it really easier to finagle some event handling using vanilla js/jquery or pull down create-react-app and get all the tooling necessary to 1-click-deploy to Heroku, S3 or Github pages and not have to deal with the multitude of bugs that hand rolled events and state can cause?

I am not sure exactly wtf a "highly immersive" experience is, what I do know is I'm shipping marketing pages that take like two minutes to load on "slow" connections and "old" phones (a.k.a. "our real users") and don't have top-of-page content or layout figured out (a.k.a. do their job) without a shitton of JS, CSS, a front-end "framework" and we can't ship new functionality (a.k.a. do our jobs) without a huge conversation about components, assets, and how the build process should work, disagreements on pet patterns.

I wish I could rebuild the home page in server-rendered HTML, a minimal hand-written set of JS and CSS for top-of page plus a fairly lean set for everything else, cut down to two fonts (headings and body text), preload the blocking assets, defer non-blocking assets, put pages and everything into object storage + CDN, and just... I dunno... serve our users. Any build tools or automation or content editor tools should lie on top of any of the above (Most of the "immersion" or whatever should remain intact, aside from what I see as bonuses: minor improvements to consistency in type and presentation).

I have no idea. But saying that you feel like you need a project is not a counterargument to the thesis: most teams don’t need it, even if some do. Maybe that’s right, or maybe it’s wrong, but your original comment was not a rebuttal.

You questioned why we keep seeing these arguments. Perhaps it’s because nobody on the other side cares to listen?

Why are there even "sides"? it's very obvious that this new tooling can be very useful for the modern Web. it's also apparent that a certain intersection of skill set and project requirements can do better with more classic tooling. why is there a continuous need to pull someone to one side or another? whatever happened to using the most appropriate tool for the job?

Because there are two or more sides to every debate.

The “most appropriate tool for the job” is exactly what the article is arguing for.

On the other hand, I'd say applications so trivial they couldn't benefit from something like React are the exception.