It does happen, quite often, to be honest. The single most important thing in this case is to understand why it happened. A typical example is when we come up with a design proposal that I think is a good one, but turns out to be that the estimated cost of building and running it outweighs the projected revenue the product will generate. Another example would be when I want to have a particular design implemented by an engineering team but they don't have enough capacity (people, time, etc) to deliver it the way it was intended. There have been cases when it was all about politics (sadly, I must add, but it does happen), i.e. someone in higher places of power want to push their own agenda and you get overruled.
These are cases when the previously mentioned 'professional negotiator' role gets really important. These are the cases when you need to go to the people involved and try to understand their priorities and their constraints. Once you have the information necessary, most of the times you'll be able to come up with an alternative solution that is acceptable for everyone. Sometimes you can convince others to give way, sometimes you'll need to.
And then there are times when you just can't do anything because, for example, you get overruled by an overzealous CTO. In these cases, as sho_hn also pointed out, the best you can do is to make them understand the implications and brace yourself for damage control, because the fallout is going to be on you anyway :)
In my opinion, the fundamental difference between an architect and a staff/principal engineer is that architects are more generalists and principal engineers are more specialised. It does not mean, of course, that architects don't or can't have deep knowledge of specific areas or that principals can't have a wide understanding of their ecosystems, but an architect absolutely must understand the ecosystem they work in and a principal engineer absolutely must understand the specific technology stack of their choice. Understanding that every choice is a trade-off and comes at a price, that someone at some point will have to pay.
You chose the latest and greatest web framework? Great! How many developers at your company will know how to use it? How long will it take for them to learn it? How big is the talent pool you can hire from? How much time will it take to migrate your products to it? Who will support it, is it "wild west" open-source or does it come with commercial support? How does it fit with your deployment model? Has it gone through rigorous threat modelling? There are about a billion factors that may affect your choices and finding the right solution will always be a central part of the problem.
To actually answer your question about how I deal with this, this is why I do research. Let's say our product people come up with a brilliant new product idea that we don't have an existing solution for, then I'll spend some time on finding information about the available options and take notes on the benefits and drawbacks. I will try to find people who are experts in the subject and get their opinions.
What I can not do, is to actually go and gain a deep understanding of every single language/platform/framework/library there is, I'm just a human after all.
The essence of my job as an architect is commonly described as a 'professional negotiator', implying that my primary responsibility is convincing people into doing the right thing (tm). My time is typically split between two main things: meetings and research/design work.
On a typical day, I have 4-6 meetings with different groups of people. Some will be solution design discussions with engineering teams where we try to figure out how a particular challenge will be solved together. Others will be with product managers, talking about feasibility, cost and time estimation. Yet others will be with senior directors about long term strategy and infrastructure. Finally, a very important part of the meetings is mentoring. Knowing something is valuable, sharing that knowledge is invaluable.
While this may sound like a lot of meetings (and engineers typically abhor meetings) they are typically very useful and very rewarding.
The remaining time I typically spend on doing preliminary research, design, documentation and every now and then even coding, which I thoroughly enjoy.
These are cases when the previously mentioned 'professional negotiator' role gets really important. These are the cases when you need to go to the people involved and try to understand their priorities and their constraints. Once you have the information necessary, most of the times you'll be able to come up with an alternative solution that is acceptable for everyone. Sometimes you can convince others to give way, sometimes you'll need to.
And then there are times when you just can't do anything because, for example, you get overruled by an overzealous CTO. In these cases, as sho_hn also pointed out, the best you can do is to make them understand the implications and brace yourself for damage control, because the fallout is going to be on you anyway :)