Javascript and the browser environment it is still pretty much glued to (Node notwithstanding) has several major architectural flaws and some unique challenges that are particularly acute for Javascript, and a lot of energy has been expended trying to figure out how to use the not-very-strong tools in a way that can support high-quality applications without too much developer effort.
Also, some of these things are getting addressed over time, so I'm kinda going to talk about the state of JS over the past decade rather than the state it is in right now. Some of these things are being mitigated (very few things are really being "fixed"), but it's still early. These issues have historically included, but are not limited to:
1. Poor modularity brought on by being not just a "scripting language" like, say, Python, but a language actually designed to write small event handlers that fit into a single HTML tag attribute. "x = 56" defaults to putting x in the global namespace. The language did not provide modules or very much in the way of separation by default. You've pretty much always been able to namespace things, but you had to really work at it; the language did not help. (I'll also toss in the dynamic typing here, just because I don't want to give it a full slot here, but it does inhibit making big projects easily.)
2. Very poor control-flow management ability due to the choppiness of event-based programming. There has historically not been a way to maintain a call stack across events, which strips away all the tools of structured programming, a set of tools so fundamental to how we operate that we often don't see them as a fish doesn't see water. Promises and generators allow us to try to mitigate this, but at the cost of spending design budget; promises for instance introduce a second entirely new set of control flow mechanisms that mirror the base language's looping and flow control constructs, particularly annoying because you must control both error and normal flow on both of these levels.
3. The browser's interface to JS is the "Document Object Model", which due to historical reasons is a Java-designed API bolted on to the side of JS. A native JS model could have been much more powerful and easier-to-use, requiring us to burn less design budget on simply interfacing to the browser in a reasonable manner. A lot of the design churn is attempts to answer the question "How can we make manipulating the DOM more JS-native?" There are also several performance issues introduced by the fact that the DOM model, combined with the rendering model, is extremely rich; things like manipulating a node on a page vs. detaching the node, manipulating it, and reattaching it have historically had end-user-significant differences in performance, as every DOM change triggers an incredibly complicated set of updates to a widget toolkit that was designed for flexibility rather than performance.
4. Browers themselves further introduce many complications. Then you have all the security issues that arise from being fundamentally client-server with dubiously-trustable servers. You have all the details like what cookies flow between what domains and where and when, that you need a different domain for your static content both for security and performance reasons (prior to HTTP2 particularly), and any number of crazy APIs that also vary across browsers, requiring the developer to use shims for things as simple as XMLHTTPRequests because you just never quite know what you actually have.
5. I could have list "client-server" in #4 there, but it's also worthy of its own callout. Many frameworks have different solutions for client-server interactions, ranging from ignoring the problem and letting you solve it up through Meteor-like attempts to completely blur the lines between the two, and everything in-between. Client-server interaction has been further inhibited by the fact that historically, there have not been any reliable and high-performing mechanisms for streaming things between the client and server, creating a design limit around needing to be request-based, further creating a wide variety of ways of hacking around this problem, each with their own quirks.
6. As an open standard, nobody is really empowered to fix these problems in a coordinated way. As a result we're sitting on top of 20ish years of standards, some well-done, some poorly-thought out, some hackily fixed after security issues, many poorly-understood by developers, and all in the browser.
7. Finally, one must not ignore the fact that web pages continue to become intrinsically more and more diverse. The best framework for a document-centric app is one thing, the best framework for a CRUD app another, and neither of those will help you much with an intrinsically real-time streaming app like a chat client.
And there's probably a couple more dimensions I could come up with if I thought more. What you see is that there's a lot of possibilities for mitigating all these issues ("solving" is often not on the table, these are mostly fundamental issues arising from layers below the JS), and the framework churn is in many ways nothing more than people combining all of the various combinations of possible answers to these problems, looking for synergies, solving different problems (per #7), and basically frantically rifling through 60+ years of computer science theory looking for the perfect solution to problems in an environment with so many fundamental strutural issues that no perfect solution is possible. Which is also why you see such vigorous advocacy sometimes; someone thinks this is it, this solves all my problems once and for all because it worked for a couple of weeks, and only once the community has chewed on it for a while does it become clear that there's a lot of people with different needs for whom that doesn't work so much, and it also didn't actually solve all the problems once and for all after all.
BTW, none of this is criticism of the JS community, merely explanation. Given the hand we've been dealt in the web browser, lots of people trying lots of things is the best we can hope for. The fatigue is just an unfortunate, but unavoidable, side effect. The best solution for the fatigue is to concentrate more on the fundamentals being explored than the details of a particular framework. For instance, "reactive" programming is its own paradigm, with its own lore and learning; learning how to program that will also let you write better spreadsheets and be better at creating database triggers, for instance. Concentrate on the fundamentals. The fundamentals are not churning that fast.