I don't consider it elitist at all. Someone with a solid knowledge of fundamentals can often accomplish more, faster, and more maintainably in vanilla Go (for example) than an engineer who is trained in frameworks. The former can write a pretty solid pubsub/distributed queue/disruptor/stream parser/load balancer/etc. that will outperform most off-the-shelf solutions, cost very little to host, and be tailored to a specific application. The latter generally cannot.
Don't get me wrong - I run a very small programming shop and I make judgment calls every day about whether to borrow or build. My operating system, hardware drivers, compiler, dependency manager, email server (etc.) I borrow these because it seems obviously practical and I have an appreciation for the complexity underneath (although I have some unkind things to say about hosting tiny apps on full-blown linux virts, the waste is unbelievable). I use Unity for client side development for games, which is probably the decision I'm least happy about, but I simply don't have the bandwidth to deal with the monstrous complexity of client-side programming (especially in a gaming context).
Frameworks are generally bloated monstrosities that conceal performance problems behind walls of configuration and impenetrable cruft that has developed over decades of trying to make the "out of the box" experience configurable while pleasing myriad experts. They do more than one thing relatively badly, and the engineers who work with them often haven't developed the ability to deep dive into them to solve real scaling problems.
You don't get simplicity, you never get zero-touch, and your learning when working with a framework often doesn't generalize, so you're basically renting a knowledge black-hole rather than paying down a mortgage on a knowledge library.
Anyway, that's my two cents on why I think having solid fundamentals is important, at least in my line of work.