Politics are the lifeblood of requirements gathering. For architecture, they are important, but don't as often take center stage.
Requirements are about the actors, their goals and motivations, and their interactions with some potential system. People are political, and the presence or absence of certain requirements, certain turns of phrase is all part of the process.
I like to bracket the "Institutional Bias," also. I often call it the "preference" in written communications. This is a nod to the ways things always work around here. Many times, this is termed "the real world," as in "that may be a good idea, but in the real world, no one would ever do it that way."
It's hard to respond when someone tries to play the "real world" card. This is often played by people who won't adapt to a better process or deliverable. You find yourself being the different drummer and try to get them to march to the new beat, which may be an exercise in futility.
You can try to play the "new reality" card. Some people will respond to this, acknowledging that the reason they are building application software is to create a new real world in which the old preferences and limitations are removed.
However, this is a war that must be won one heart at a time. A long struggle, especially for outsider consultants.
The architecture, similarly, must often bow to skill set, experience, and novelty constraints. While many people may be perfectly happy with MySQL under Linux, there are still many more who will bracket it as unproven, risky and dangerous.
I've heard good old Unix called "too new and too risky". This was back in the 90's, when UNIX was over 20 years old. But, to someone who had never seen it before, it was too new to consider.