Language learning does not stop when one becomes proficient in it. You keep learning new usage patterns, all the corner cases and nasty surprised and start to remember libraries and their features. You become gradually better and faster in the language you use. After decade or so you can become really good.
For a really experienced programmer there is a drop in productivity even if they are able to learn and use language better than more junior programmers.
Also, food for thought: if nobody can review his code, what evidence of his "greatness" exists other than his saying so?
I write a shitload of PHP/jquery - and no one reviews my code. If it's done fast and works as expected my bosses don't care... and they'll listen to me over the front-end dev who wants to use React/Ruby.
Now I don't 'hate' any language and will try new things, but my point is that the definition of greatness can be completely different between companies, especially when the company isn't a tech company.
What good are they, then? If the decision to use Python has already been made and acted on then a mediocre Python programmer who can actually commit would be more useful that a genius whose code is useless to the project.
- What is my budget - How much time do we have to deliver the project - Is there an ecosystem I have to integrate with - Do I have strict performance/safety guarantees - Are there libraries that I can delegate to
Python is a fantastic language, but I wouldn't use it for everything. However, I will agree that just saying "I don't like it" is not a good enough justification for dismissing it. That just seems unprofessional IMO.
In my experience, if you have a language with a compilation-like step, e.g., assembly language, then you automatically have a massive advantage over a language without, e.g., Javascript or Python.
The advantage over languages such as Javascript only grows wider if you opt for a language with a comparatively sophisticated and thorough static type system, e.g., C89.
Now, suppose the Javascript code has 100% test coverage, and the C89 code has 0%. But so what? I was assuming that already. In my experience, the C89 code is still easier to work with.