I think maybe I just struggle with the concept of being that hands-off with the tooling. I don't think I could cede control to some one-size-fits-all solution. For example, what happens when you run into some important library that doesn't tree shake or minify properly? What do people do? Do they just pick different libraries for the wrong reason? Do they just deploy an un-optimized application?
Not knowing how the stuff you depend on works feels really scary to me. Reminds me of the Star Trek TNG episode about "The Custodian" where the colony came to depend on a tool that nobody knew how to fix, so their lives were shaped by the tool's abilities, not the people's desires.
And on top of that, it's all different now. I'm not as interested in trying to maintain all of that, on top of maintaining my app. CRA is a fantastic tool for this.
Until it breaks down leaving the project in an unmaintainable state, you're right. Then it's a scramble to understand and update that in my experience usually results in locking that dependency down to a strict version number and hoping that won't break anything else. It's great for security as pointed out in this thread /s. Not the optimal solution, but then again, they don't pay me enough/have enough staff for the optimal solution. And this is code that isn't even part of the app! Just shitty tools preventing me from even building the app. I can relate to the people complaining on here. This is with one or two dependencies too. Try solving those issues a few thousand times. You'll wish this horrific trend of front end code compilation would just stop. The problems truly never end as soon as one has to deal with npm and js dependencies. Which is not to say other languages don't have the same problems. They do, just not on this epic scale of shit.
mkdir parceldemo
cd parceldemo
yarn init
vi index.html
vi index.tsx
npx parcel index.html
...and I have a working React app, with hot module reloading and TypeScript. Parcel installs TypeScript as a devdependency and react and react-dom as dependencies, and starts the HMR server. It took less than one minute.
Most people don't remotely know how Webpack works. And they shouldn't have to! Same for most other developer tools. You need a few people who can dig out issues if they arise, but most of your people will be concerned with actually building things on top of those tools.
When every team starts a new project from every few months to every few years, having a boilerplate setup quickly becomes very valuable. The added benefit that third-party boilerplate has is that you don't have to maintain the whole lot yourself.
Needless to say these upsides don't come without issues, security and accountability being the big elephants in the room, but popularity helps here, too. The boilerplate is used by a lot of people, in organizations both big and small. If an issue arises, you can usually collectively work out the problem very quickly. It doesn't make the issues go away, but it gives you a good balancing point.
As a tradeoff versus either setting up every project manually or maintaining your own boilerplate project, it's definitely worth consideration — it might not match your needs, but it's a strong option.