Because that's what leads to monumentally difficult to use tools.
Instead of choosing between gulp or grunt, you'd need to choose which config flags you want for this hypothetical "gunt". So instead of having simple to use tools (but a bunch of them), you have a few tools which take weeks of learning before you can even scratch the surface on them. And it leads to tools that have settings that nobody knows about because nobody uses them, and weird security holes and issues because of legacy support for an option that was added 3 years ago which when combined with a new flag causes everything to break...
Gulp is very simple, it's like 4 functions, and like 3 or 4 "conventions" you need to learn. There is no config, there are no settings, and there isn't any baggage. And that's the theme with JS tools. Rather than bloating current tools, you make a new one. Switching between them is easy, as they are all very trivial in nature. The power comes from combining those trivial tools.
Even if that were the case I would think learning powerful tools over the span of a few weeks would be worth the effort if you had the reliability that these tools would exist for years to come.
It seems like the rapid change and throw-away-ability of the tool ecosystem reflects the final product as well -- and maybe that's the large difference which is emergent from web technology? What is the average lifespan of a web application?
I don't think the past few years will be representative of web development in the future. The community has had a lot of churn because basic questions (How do I ensure my code has what it needs to run? How do I include dependencies? How do I efficiently deliver my code?) weren't answered, but now those questions have robust, widely used solutions, we don't have everyone figuring that out for themselves (and writing throwaway tools).
I think most of the current crop of tools that are in vogue will stick around for a while. There have been a few challengers to Webpack offering feature improvements (Rollup, Broccoli), but the ideas they introduced were added to Webpack, rather than replacing it.
I use maybe 3 main tools for my build system. Gulp, webpack, and babel. And I only use gulp because it is a bit easier to read than just putting stuff in a makefile (which is replacing one tool with another), or just using bash scripts.
If we were going with the "add options instead of adding tools" way of doing things, I might have one tool, but 100 flags and settings that I would need to manage and change, and you can't ignore the flags and settings just because you want defaults, because the defaults would work in a way that's out of date, or there might no be defaults at all.
Just because there are tools out there, doesn't mean you need to use them all. You can ignore everything you don't need in your project. And that includes ignoring the downsides, bugs, security issues, breaking changes, and baggage that comes along with them.
In half the cases parent presented, there were no "existing tools" to update(manual polyfills -> modernizr/6to5, script tags -> package managers like bower/npm, nothing -> eslint/type checkers, writing ad-hoc scripts for your own os -> grunt/gulp).
The rest of the examples are cases of merging two large ecosystems(web development and nodejs) together - that spawned browserify/webpack for bundling, npm for package management.
Many of these tools did try to update and adopt the new schemes. The grunt developers spent a lot of time optimizing their architecture in order to achieve the same speeds that gulp had. NPM has not stopped evolving - major version 3 tries to address a lot of the problems that yarn tackles. Babel evolves to adopt new javascript features.
I see the churn in development tools as a very natural progression, but that might be because I've been following it for a while and have seen and felt the pain points that each of these tools try to solve. I see a lot of effort within the javascript community to remain "compatible" wherever possible - for example, there are tons of guides how to migrate from grunt to gulp, there are matching tasks to ease your migration, etc. Library developers often release both on npm and bower, and craft elaborate "UMD loaders" for their libraries to allow for commonjs/AMD to exist side by side.
All in all, I find living with "javascript fatigue" to not be very exhausting. In our company, we have a wide variety of projects - some use literally no tooling, some use just bower, some use grunt, some use gulp, and our latest ones use the "modern stack" with webpack, etc. All of these projects are still actively maintained and their respective tooling stacks work and provide the benefit they were added for.
The problems the "newer" tools try to solve may not even be problems your development process has. If you've never really suffered performance problems working with grunt, then perhaps you've never felt an urge to migrate to gulp. Maybe you've never been bitten by npm's non-deterministic installations and poor download performance(I really haven't, so I haven't migrated to yarn, for example).
The magnitude of web development projects has ballooned in the last couple of years, and the tools are racing to handle it. It's not surprising that tools that are fit for a large web application with tons of code and a large team aren't really fit for a few javascript files to decorate a mostly static site built by a single developer. The churn is there, if you need it, but you don't have to use any of the newer libraries or tools.
