Especially in the post refactoring era, they tend to have an inaccurate account of what the code is actually like and make bad calls based on bad info. It’s a responsibility that works better when the people have their hands in the code. I’ve had better luck with Architecture as a job description shared by the lead developers. In large enough companies they have Staff Engineer that scratches that itch with perhaps slightly less people skills (though I really don’t recommend it).
People talk about enterprise architects as these pie-in-the-sky people who shit diagrams and everything works wonderfully. In practice it's "seagull architecting", with everyone else forced to deal with the reality on the ground.
At some scale architects need to be more hands off. When that happens they need to have a _very_ strong relationship with the people on the ground or it doesn't work well. Even then I would argue they should be getting their hands dirty in terms of reading code, etc, they just may not have time for implementation duties.
Sometimes you pick the simpler tool, and hope it has legs. Sometimes you tweak your product roadmap to dovetail with the tool’s. Sometimes you push to get 25% of a feature set released so you can make progress. Sometimes you temporarily add another tool, and sometimes you fork for a while.
What most people just do though is measure power of the system, ignoring the Principle of Least Power for third party code, if not in fact for the entire project. Approachability is often better than power. Quickly knowing what a tool can or cannot do is generally more productive and results in less politics (who hasn’t worked on a project where person A keeps criticizing Group B for not knowing the framework can just do the thing they wrote, but it’s not immediately obvious that it can? That’s someone tearing down the team to boost their own ego. I don’t like it. I liked it even less when I was the one doing it. Don’t be That Guy, he’s an asshole)