> "Boilerplate" implies copying a bunch of code into your project that should be library code but isn't because it's too poorly designed to have an API cleaner than "just fork it, YOLO". It's dramatically harder to update than something with well-designed API boundaries.

In most of these cases, "boilerplate" implies a choice of frameworks, libraries, build and test tools, with a minimal or recommended configuration, all tested for interoperability. The actual code advancing your application is minimal.

In the case of megaboilerplate, it appears to be a mix of configuration files plus a mini hello world built on top of the technologies. The mini hello world seems to be mostly a demo of how the chosen technologies can interoperate, not really something that "should be library code".

> Shared, standardized toolchains are harder to build but once you do they're a dramatically better long-term investment.

Possibly, but I think you underestimate the effort required to create and distribute a toolchain that would become shared and standardized. In effect, a specific team might choose a particular boilerplate, tweak it to its needs, and the tools and libraries within that boilerplate become their "standardized" toolchain.