(And by the way I realize in a lot of companies, 'architect' is a completely bogus term for someone who's more of a flim-flam man than actual doer. So just substitute "staff engineer" or whatever you call it.)
But the main parts of my job I have to get right are picking the right approaches technology-wise, and setting up frameworks and patterns to make devs' lives easier in building out the actual features. You can't test that stuff on a whiteboard imo. You have to just talk it through and try to get a sense of how the potential architect/lead thinks about problems.
It also takes a good architect to interview an architect imo. There's plenty of great devs who just haven't acquired that level of scope yet - not of thinking not just about how easily it is for you to get something done - but how easily it will be to maintain as a team, within the greater ecosystem, over the life of the product.
And that's the underlying problem behind this coding-test nonsense. You don't ask an architect candidate to implement a binary tree in an interview because it's relevant - you ask that question because you don't know how to ask questions that are relevant. For anything but actual low/mid level coders, these coding tests are just evidence of a failure to interview effectively.
As an aside, I don't find most architects to be "flim-flam men". They are usually quite hardworking and competent, although their job is frought with risk. They're often asked to do the impossible, and they have to do the best they can with it.