We're already allergic to frameworks where I work and we're slowly moving away from libraries as well given how low quality the average open-source library is. Once you realize you spend more time debugging open-source libraries than your own codebase, you stop caring about popularity.
If you hire developers for what they know right now, of course you'll limit yourself to only the popular languages/frameworks. Its much more lucrative to hire developers for their potential to learn and grow; these people will make the best of any language/library/situation.
Of course, like you said, economics come into play but my point is that the popular choices often lead you to a path where you end up with a lot of mediocre developers, terrible architectures and endless conceptual debt. At the end of the day this is much, much more costly and doesn't even yield quality software.
See, the problem is, you still need to use frameworks and libraries, you just end up rolling your own, and now you are responsible for supporting and documenting all the different use cases your developers have. If I have an issue with, say, React.js, I can tap into the pool of the thousands of Stack Overflow questions and discussions, whereas I can't do that with a home-grown framework. Unless I'm doing something really low-level, I'll take the thing that has had thousands of man hours poured into it and an entire ecosystem built around it over the thing that you made because you're "allergic" to open source. You're going to be debugging someone else's code anyway, but the time spent doing that with open source frameworks is offset by the time saved because you don't have to build everything from scratch.
I won't have to write my own framework by not using one, while it may be easier to use one, its far simpler not to use any. You spend so much time trying to fit your use-cases into the framework's paradigm that its usually much faster to just write from scratch. Every single framework I've seen so far had huge scalability issues, they're easy to get started with but you end up crippling your agility as the codebase scales.
As for rolling our own libraries, we can make them specifically for the use-case at hand without anything extra. What's the point of using a few dozen libraries when you only use a fraction of each and now your bundle is megabytes in size? And that's not even counting all the extra code required to wire them all together. There's a reason why we say the web is bloated.
Also, isn't the alternative of debugging open-source libraries writing the functionalities you need yourself? Working with faulty open source library is tedious, but that work can be seen as way to contributing your time to make open source library better for everyone.
Most libraries out there will do a LOT of things I couldn't care less about, making them harder to integrate and debug and reason about, on top of bloating your executable.
I do agree there are a lot of amazing libraries out there and we do use a lot of them. But that's after analyzing them and figuring out they solve our problems and actually will save us time. For the vast majority of libraries we look at, its usually faster and better to roll our own.
That's wrong. Every civic engineer I know, for example, would prefer standard, and lacking that, popular nuts, bolts, construction parts, materials etc, over niche ones, unless there's some very pressing reason not to. They are cheaper and available in greater volumes, you can find skilled workers easier, their properties are more studied, etc.
That's even more important in programming, where ecosystem, availability of libraries, continued support on the language and compiler, availability of skilled programmers, existing codebase support, etc, matter even more than pure language level issues.
Popularity in a language is crucial, to the point that other attributes, like expressiveness, or even speed, can be inconsequential compared to that.
And while engineering can be a pop culture (e.g. Mongo or the latest fad), popularity is important for aspects that are totally counter to pop culture too: namely, pragmatism.
Programming is not about using what's "best", it's about using "what's best given business constraints" (which is something else altogether).
Besides, the hipster figure who listens to obscure music because it's "best" is also a pop culture phenomenon -- not to dissimilar to certain programming cults.