Those frameworks introduce a necessary complexity when used to solve the right problem. Generally, when the necessity is to solve the human problem of building with diverse and disparate systems, not the technology problem of semantic interoperability amongst the systems.
The stack gets bigger as we look closer. Eventually it's less to learn a framework, than to learn the stack.
On the latter technology problem of semantic interoperability, the more frameworks the more complexity. Nothing I have until now or am likely to on work in future will be, as a coder, within a team of sufficient size or towards a deliverable of sufficient complexity, that the frameworks are the less-complex option. This is the reason I do not currently see any value in pursuing a working knowledge of most of those. I like to work in detail throughout the stack.
On the former, human problem of building with disparate systems, the more junior and inexperienced the team members the greater the bulk of work which may be considered 'diverse and disparate'. Thereafter the more early-career adopters of the large frameworks. This gives us delays in the development of tradecraft, though perhaps not the development of the short-term reward of monetary compensation. This aspect makes me a little sad about the whole thing, but I know that some diligence and practice with whatever will go a long way. They'll find the way lower down the stack eventually.
I am a little long-in-the-tooth at twenty years into a devops career. I choose to work the same issues of human complexity that give rise to the utility of the mentioned frameworks, without the specific need to become adept with the frameworks themselves, by developing skills as a guide and teacher of the trade in general. The biggest challenge I have and continue to deal with, is seeing the beauty of some of these frameworks that I don't wish to personally use, for various reasons.