Earlier quoted context omitted.
The team has a culture that knows full well someone is brought in for who they are ... what they know might need some catch up. I'm not saying this is right in all circumstances. I wouldn't do this with, for example, realtime embedded. For what I operate in, fairly bland web applications and stacks. It works fine, exceptions excepted.
The team has a culture where the leads know less than they do and they are okay that?
The lead may know less than them about some things. That's OK for us. But what's important is they know more than the team about other things.
For example, we would rather have a lead that knows when to say "How do you know this is performant? Show me." and understands statistics and how to read perf dumps ... than how to profile whatever PHP script or whatever hands-on.
Sorry that contradicts the black-and-white world view you're holding.
I also strongly believe good technical leadership is about accepting you know _less_ than a team, and being able to ask the right technical questions to the right people who know more than you to ensure the best outcome.
You can do that with a ground knowledge of the stack, picked up on the job, along with learning the application's code and architecture. What a good technical lead brings is a deep understanding of how to manage complex people and systems by having done so across different languages/stacks/architectures many times.
Why would I turn away someone brilliant at that because they happen to know Java but not Android development? That's the easy bit to solve.