I would be interested to see how the products turn out in the long run, when the team decides on architecture A but the company as a whole bets on architecture B, e.g. the team likes AWS but the company wants to use Azure.
Of course, camels are pretty cool. If you read Pratchett, they are the world's greatest mathematicians.
But they ain't horses.
There's a lot to be said for a single, focused, experienced, architectural "czar."
As to how much leeway the team is to be given, I think the jury is still out, and I'll bet it depends on corporate, or local societal, culture.
Team overhead is a big deal. The more leeway and autonomy that is given to the team, the more overhead is required to maintain the product focus and lifecycle.
But it can well be worth it, if the team is comprised of experienced craftspeople. Less so, if it is mostly junior-level folks, who need to "stay in their lanes."
I am not a fan of "One Law to Rule Them All, and In the Darkness Bind Them" rules. Every team, and even every project, will have many factors that will inform the structure, overhead, deliverables, quality, future maintenance, etc.
That way, there's someone who can challenge your opinion and you have to convince them to agree with it or find an alternative. Often during the convincing part you identify issues that you wouldn't have thought of by yourself, and since you don't have ultimate authority by yourself, you're less likely to unintentionally shut up someone who wants to disagree but defers to authority.
e.g.
If one team decides to use Protocol Buffers for their public APIs instead of HTTP/JSON that is the standard, that needs to be discussed at a higher level. As that decision forces other teams to change their tech-stack, one team cannot make that change unilaterally.
If the team's application is composed by several micro-services and they want to use Protocol Buffers for their private/internal APIs, that is not a concern for anyone else.
The directors or architects will be arbiter of the discussion to make sure that it is taken fast and everybody opinion is weighted in. And, if the end there is no agreement, then the director will take the decision to keep things moving.
The main downside of this approach is when a team changes project and ownership of the code changes hands. In that situation you get a tech-stack that you may not find attractive. Usually the team will end changing that tech-stack to something they are more comfortable with, but it takes a long time.
The rest of it doesn't have to be an explicit override, but asking the team for clarification: "You've spec'd out A but we do have B that is similar, is there something missing from B that you need?"
The problem with a top down approach is that the architect doesn't actually know what is actually needed by teams. They're too far removed from the day to day. So you get a uniform but generally suboptimal set of technologies.