While this addresses some common problems that need solving, there are some very strange leaps of logic in your post:

1. The choice isn’t between ‘frameworks’ or ‘boilerplates’. The third (and most desirable!) option is modularity with composition, which requires neither of the two aforementioned. As a developer, you will have to learn your tooling anyway, and so the solution is to contain complexity for individual tasks as much as possible, not to make (automated) copy-pasting easier.
2. You’re presenting copy-pasting as something that needs to be accommodated. It’s not. Copy-pasting — whether from your own code or somebody elses — should be considered forbidden entirely. If you want to reuse somebody elses code, use a module. If you want to reuse your own code, create a module.
3. The choice also isn’t between “modifying NODE_PATH” (or whatever Webpack’s equivalent is) and “endless ../../../”. There’s a perfectly functional solution for this in the form of `rfr`, which will not cause conflicts like you described and remove the need for `..` entirely. Incidentally, this is one of the reasons why ES6 Modules are a step back — they don’t allow for abstractions like this. Stick with CommonJS.

I’m also not sold on the “everybody will build their own framework” argument. This is something that simply isn’t necessary when composing modules, and doesn’t make sense anyway — every project will have different requirements and so require a different assortment of modules and tooling.

That having been said, I do feel that there needs to be better documentation on how various things tie together. That’s something I’ve been working on myself, in fact.