> I've used the same React tech as the basis for most projects for 6 years now. Webpack, Redux, Yarn, React Router, all still popular and maintained. We even used hooks for functional components since then, through the "recompose" library, so there wasn't a big paradigm shift for us.

Have you worked at different companies or contributed to different OSS projects in those 6 years? If you have, and they've all been set up exactly the same as what you mentioned, that's rare, but great. I think most people's qualms on the amount of different frontend tooling is based on the fact that almost every company or OSS maintainer takes different approaches to accomplish essentially the same thing.

> that's rare, but great

Not OP. At a big tech company. As far as I can tell neither myself nor anyone I work with has touched a system developed in the past 6 years that didn't use React with with Webpack and/or Esbuild for the build system. Of those, 90% + used Redux for state management or switched to Redux after starting with a different state management system like mobx or xstate. The only exception to this the only exceptions are apps that needed something Recoil-like (e.g. Redux caused too much computational overhead). Some of them also used Nextjs for static pages.

I’ve experienced similar thing wrt the build system, but haven’t used redux in all but one of the React projects I’ve worked on as a full time product engineer over the past couple of years.

Yes to both, and I can't say many projects followed a radically different approach, at least without good reason. Webpack and Redux for example are many times more common than something like Parcel or Jotai, so it's rare to encounter many of these alternatives in one project.