You are thinking like a founder, you need smart people to solve problems, not a react engineer, or a vue engineer etc.
Most job postings are usually created by recruiters that get details from the teams on what skills are needed. So the ads read like an ingredient list of sorts.
And like you said, the job ad needs to state what the responsibilities are and should detail the current stack so people know what they are applying for, but that shouldn't be used to exclude quality candidates. I have hired people with no experience in a specific language but by talking to them they were highly competent engineers and I wasn't worried about them picking up a new language.
One of my major disagreements with the current hiring methodologies is that it rewards people who study for a test of sorts but may not really have experience solving real world problems. Or other "tests" that focus on whether someone can write some useless piece of code just to satisfy the interviewer that the person is competent. But the reality is it never accomplishes what hiring engineers think, because they didn't really talk to the person to figure out what they know, what their experience is and whether they understand architecture or coding choices really. I've been interviewing engineers (as well as everyday business team members) for somewhere around 25 years now. I went through the dotcom boom/bust where we did some weird interviewing methods many that seem to have made a sad come back again. And the key thing hiring always comes down to is understanding peoples decision making process more than their ability to write code for this contrived problem in the next 2 hours.
I do not use coding exercises at all with candidates, and I do not give them take home tests or anything of the sort. I have found it commonly eliminates the very people I need to attract. I want the guy who is smart and thinks through problems and who has experience and values his time. I want the guy who when he sticks his resume out he has 20 people wanting to interview him and he doesn't have the time to do everyones 4-6 hour "test" plus another 4-6 hours of interviews, because if he did that for everyone he'd drop the ball at his current position. I want to talk to these people, I want to walk through problems with them (sometimes walk through code I provide so they can comment on it and I can ask them questions), I want to talk about what they have solved and how, and I need to see that they can communicate with me & the team as well as fit in. Of course I ask them specific language questions if I am hiring for a specific need, but I don't care about seeing them write some piece of code in the next 2 hours, I just want to know how smart they are and where they have weaknesses (since we all do). And I need to hire people that complement my teams weaknesses not multiply them.
*edit to add this -- Also the reason I can hire really good candidates before others most of the time is my rule is from initial contact to decision is 5 days or less. That means while other companies are screwing around we already made a decision and gave them an offer or passed on them. Most startup hiring processes take weeks to get through and suck up a huge amount of time from company engineers, founders etc taking away from dev/product time.