I have a nuanced view of your particular example. I've been in this industry for almost 30 years. I cut my teeth writing C/C++, had an interest in language theory and frameworks and was brought up to care about portability. I always wanted to be able to easily transition from one language to another, or one framework to another.
And I always assumed this was the case for other engineers in our field as well.
However, I have worked for startups that like to move really fast, and hired talented developers who passed our technical screenings (read: "had the fundamentals down") under a "framework agnostic" hiring policy ... only to see them display stunning degrees of incompetence trying to learn our tooling.
The problems that compound this are:
- When you enter a new company with a large codebase that you have to ramp up on, you're not only required to learn the language or 3rd party frameworks and libraries that they use ... you need to ramp up on THEIR "framework." Depending on the complexity of the system, there is a lot of domain specific knowledge and custom supporting code that will have been written. Try to learn the ins and outs of Angular change detection, for example, while also ramping up on a massive codebase that does things in weird ways for legacy and historic reasons.
- Every business, but some more so than others, has time pressure. You need to be able to write functional, easy to maintain code but also get it shipped yesterday. If you come into a company unfamiliar with the languages and tools that they use, you are essentially coming in handicapped. Expectations that you can deliver are very high, despite the time that you need to ramp up. Maybe you're one of those 10x'ers who can learn all the ins and outs of a new tool in a week or two before starting your position and then apply that knowledge at the level of someone whose been working with the tool for years and has learned all of the hidden footguns ... but if so, you are a rare specimen indeed. The industry can save itself a ton of inefficiency if it takes a "better not take a chance" attitude.
- All problems are people problems. It's not that the company needs people who know how to code in the language or tool ... they need someone who has worked on enough different projects with that tool that they can navigate the completely fucked up ways that THIS company uses it. Because THIS company will for sure have years of active development behind it by developers of all sorts of different experience levels ... and some of those developers did it the right way while others found creative solutions and did things weird. The company doesn't need someone who can write the Hello World tutorial in the language or framework, they need someone who can evaluate the good decisions vs the bad ones in an existing codebase.