Any programmer of less experience who continues to argue with the "Architect" after they have met the challenge of proving their ideas can be done should also have to get a new job.
Many less senior programmers are better at the every day idioms of a given language or tools used in daily programming. Many senior people have to do more than just code. But most senior people who can still practice if called upon are much better problem solvers in part because they have already failed so many times and each new batch of programmers keep re-inventing the same mistakes.
A2)Probably don't have to worry about it.
I like people who want the right answer more than those who want to be right.
On the other hand if you're drawing diagrams of things you haven't personally made sure could work well together at even a trivial POC level then I am not a fan because that is precisely why some devs hate anyone who is called an Architect.
If you're producing work products that don't accomplish their job, then you're probably just not good at your job, architect or no.
In this case, the diagrams are to guide development toward an acceptable conclusion, but if they instead impede or misdirect development then you failed.
Fortunately, there _are_ lots of ways to validate a technical design, among them toys & POCs, but also rtfm, reference works, etc...
The architect needn't rough things out in code all the time, though.