I do the same. I find it much easier to understand and I've always needed to modify the config anyway. I wrote about my own boilerplate in https://www.vincentprouillet.com/blog/react-typescript-webpa... and the Webpack config is like 75 lines. It could work with Vue or anything else just as well.

My guess is people still think Webpack is hard to configure despite that being quite simple now.

I have my own babel+webpack+etc repo I clone for mini-things I want to dig into (e.g., how does "tool x" work?) and I can freely explore learning that tool, without clouding my production important code base. I then transport those learnings back, and the implementation is more refined, since it's clearly written by somehow who knows how to effectively use Tool X, without haphazardly throwing it around.

That's a good strategy, I occasionally use that too, but a better strategy is to keep isolating often repeated functionality in your project and turn them into library packages, so you can simply add them as a dependency from now on. This way, you boilerplate becomes smaller over time or you can even start from scratch easily.

The repeated functionality that belongs in a boilerplate is literally all that CRA does. That's what makes a boilerplate a boilerplate.

I do the exact same. I find this is especially important where license and dependency management is a concern.