If we let you tweak them, any minor update on our part would be a breaking change. We wouldn’t be able to introduce new features or update the underlying tools without a lot of risk. This is why we don’t let you change the configs.
If you have a specific pain point, please file an issue. I think we can make defaults better. It takes more work but is more rewarding in the end because it benefits everyone.
This is super useful for helping beginners overcome initial barriers and quickly become productive, but do you see this as something that most will eventually grow out of?
That makes sense, but I think there will always be people who want to tweak ESLint rules or enable new Babel features, but would still like to take advantage of improvements to this project.
Perhaps exposing a subset of those tools' configuration options would be sufficient.
Alternatively, you could imagine a pretty simple system that allows you to pull newer versions of the "ejected" code and handle merge conflicts using your version control software.
I'd also suggest reducing the amount of non-configuration code that's generated by "eject". I think basically everything in "scripts" could be put into a package ("openChrome.applescript" seems like it should be a feature of opn anyway). That would also reduce the number of devDependencies that need to be added to your project's package.json (rimraf, chalk, opn, etc)
If you have a specific pain point, please file an issue. I think we can make defaults better. It takes more work but is more rewarding in the end because it benefits everyone.