The technology choices follow on from this. If you have a smart team, then you can pick technologies that solve the problem most efficiently, rather than the lowest common denominator that everyone will be able to use, or what's most fashionable (you see this in every field: the "good" people are often following trends or best practices (and doing it well), but the very best tend to have a much more nuanced judgement. They know about the latest thing, they'll use it sometimes, but they keep their own council, and they're not afraid to go off and do something unorthodox if it makes sense for the situation they're in.
---
Side point: Incidentally, React is actually on my list of go-to productive boring technologies. It's definitely overused (despite building React apps in my day job, my personal website is built with Hugo, and a lot of sites would be better off with server-rendered Django/Rails/Laravel), but where you need that complex client-side interactivity I think it's the generally best tool for the job.
^ This. As the project gets larger you can't find enough "star programmers" in a timely manner and have to fall back to mediocracy. Read "The Mythical Man-Month" and the associated Brooks' Law for context.
Could you elaborate on that? What were problematic?
I wonder what the deciding factor is. I used to be part of a Haskell team and it was actually net negative vs. just using something really batteries included.