A way I think of this is to categorize skills by whether they'll last a decade.
Python, SQL, Linux, those are core skills I've used for over a decade and are just as useful as they were a decade ago.
Javascript is obviously more than a decade old but a reason I've avoided that ecosystem is that you're often operating in the domain of year to year tools and skills on top of it.
Decade long skills come as easily to you as English. (Or whatever your native language.) It's easy for people to overlook this because it's so easy to "learn" a skill right away and feel fluent.
I've optimized for keeping as much of my work as possible/practical in decade long skills because it's pure productivity. If I'm turning over frameworks and tools regularly I'll still be productive, but not productive. I see it as a qualitative difference, not quantitative.
There are a plethora of different ways people are using all of the tools that you mentioned.
There are so many SQL implementations and flavors, no one could possibly have a thumb on all of them.
Acting if it is somehow easier to master than the many web development tools (frameworks, build tools, etc) that you can learn how to use in a few hours seems like a confusing take.
Now I find this fascinating. Working with JavaScript, I've just come to assume continual training is part of the job -- but what if it didn't have to be?
Of course I still learn new skills in the Python/db ecosystem, but I stick to the fundamental Python/Postgres/Flask/Django/Redis/Nginx stack where possible and it not only helps productivity but it reduces surprises. We understand the exact risk profiles of these systems. You can "learn" a new tool very quickly but you won't know how to assess or reason about what will be the operational experience of it in production. We do not factor surprise tolerance into our decisions often enough.