1) need for capability that old method doesn't meet, so new tool is made
2) dev working on both simpler and more complex sites, wants everything to use the same tools
3) even sites with simple needs now get done using tools powerful enough to satisfy needs of complex sites
4) experienced dev doesn't see a problem, because they are conversant with those more complex tools, and also don't often get assigned to do simple websites anyway, but anyone doing the (considerably more numerous) simpler websites now is getting their groceries by flying a SpaceX rocket from home to the grocery store.
5) now that websites can do more, and very occasionally do, someone thinks of something else they want a website to do, and the cycle repeats
I think you forgot one driver, which IMHO is a major one:
Imagine you are just getting into the business and are confronted with complexities, which would let you come to a grinding halt for the next 6 months until you have at least a foggy idea of what is going on. (Angular, Elm, PHP, React, ...) And once you worked through your initial list of "need to know", 5 more have popped up, like a hydra where chopping off heads just results in... more heads staring at you.
So, in this situation, it is quite reasonable to try and "get ahead of the curve" instead of lagging behind the ever changing world. You decide to write your own framework (based on your current and imperfect understanding), ignore what is already out there and pass the ball to anyone else. They have to look what you did now and read your stuff and scratch their heads, while you can be productive. And it feels good. You feel like a messiah. You can publish even a book, maybe and hold some enlightened talks.
This is the result. New generations are literally forced into re-inventing the wheel to even stand a chance at getting something done.
And its not only in web design/javascript/web-assembly/call-it-how-you-will.
The same happened e.g. in the Microsoft ecosystem (desktop programming). MFC -> ATL -> VB6 -> .NET WinForms -> XAML -> Silverlight and back to XAML -> .NET core -> however it will go on (I detached at that point, having run 'too many laps').
And since someone mentioned Linux... what is the canonical way to write GUI apps in Linux these days? Tcl/Tk? xlib? xcb?, SDL2, wayland over X? Gtk, that huge google framework? QT? SDL2? Motif? Pure wayland? Also a huge mess and people "innovating" just to be ahead of the curve. Yes, there are always reasons, if you need them to be...
> And since someone mentioned Linux... what is the canonical way to write GUI apps in Linux these days? Tcl/Tk? xlib? xcb?, SDL2, wayland over X? Gtk, that huge google framework? QT? SDL2? Motif? Pure wayland? Also a huge mess and people "innovating" just to be ahead of the curve. Yes, there are always reasons, if you need them to be...
There isn't a canonical way - Tcl/Tk, Qt, Gtk, SDL, Java, pure graphics backend calls all continue to work. All as long as there's someone out in the world with enough dedication to them to keep them up to date. Linux ecosystem is not at mercy of Microsoft or Apple, thankfully.
Linux is still very much GTK, Qt, and to a lesser extent, Tk. There hasn't been nearly as much rotation of core libs as there has been on Windows or the Web.
1) need for capability that old method doesn't meet, so new tool is made
2) dev working on both simpler and more complex sites, wants everything to use the same tools
3) even sites with simple needs now get done using tools powerful enough to satisfy needs of complex sites
4) experienced dev doesn't see a problem, because they are conversant with those more complex tools, and also don't often get assigned to do simple websites anyway, but anyone doing the (considerably more numerous) simpler websites now is getting their groceries by flying a SpaceX rocket from home to the grocery store.
5) now that websites can do more, and very occasionally do, someone thinks of something else they want a website to do, and the cycle repeats