Most folks won't need to customize the standard CRA behavior. If you do, there's the community override tools.
As a specific example, two years ago I wrote a tutorial on how to use the Cesium 3D globe library with Webpack [0]. Loading Cesium at the time required changing two Webpack config options, so my tutorial started with "create a CRA app, then eject".
I recently set up a brand new CRA project that also uses Cesium. I could have used `craco` or a similar override tool to apply those Webpack config tweaks myself, but there's actually a `craco-cesium` plugin [1] that applies those edits and handles copying Cesium's assets to the CRA build output folder. This new project didn't have to eject at all.
As another example, that same project also needed to do more customization to the dev server proxying setup than CRA normally allows. CRA lets you define a simple `"proxy"` option in `package.json`, or a `setupProxy.js` file that gets a reference to the Express app to add middleware. I actually needed to apply a proxy middleware at the _end_ of the chain. `craco` let me access the actual Webpack config setup to do that [2].
The other nice thing about these override tools is that your modifications are isolated in one place, so you know exactly what changes are being made. If I were to eject and get all those config files in my project, yeah, I wouldn't know what had been edited from the originals without digging into the Git history. This way, it's one `configOverrides.js` file at most, and I get all the benefits of the rest of CRA's config which has had thousands of man-hours put into it.
[0] https://blog.isquaredsoftware.com/2017/03/declarative-earth-...
Re-loading ny app i to a new CRA harness seems possible but fiddly. The last time I tried I got bogged down in dependency hell because so much had changed (unusual things like my auth library failing when backed by a more modern React). It all remains on the long-term aims list.
I don't think there's that many uses cases that can't be done within CRA. I think there's very limited reasons to eject.
Also, it'd add more substance to the discussion, but I really am curious how many people eject. Is it, the minute it (CRA) can't do what you need, you have to eject? Or it becomes exceptionally difficult to interface with a tool that just abstracts away more tools? It's possible those abstractions might not give you the full level of customization would could potentially need, if project requirements shift.
CRACO seems like an admission that CRA, on its own, could be somewhat half baked. The ability to want to override some things without fully ejecting seems like an obviously wanted feature of a toolkit.