There is indeed bias, but working at a company with a similar committee process, the committee process does indeed introduce its own series of biases and failure modes.
For example, depending on how the committee is chosen and the size of the company, you might still be known to the committee.
Popularity therefore still matters a great deal.
This isalso why my work inbox is chock full of weekly, biweekly, and monthly updates to products and features that are completely irrelevant to me, my team, or even my domain.
Complexity is hard to measure and somewhat subjective, but might be an important metric for promotion.
With potentially less specific domain knowledge available to the committee, something that seems easy might be extremely complex or vice versa.
Maybe you make something so easy and configuration driven engineers can delegate to non-engineers.
Now your job looks easy, but it took months of research to come up with a schema that can encode global tax rules (made up example) and only a few weeks to move hardcoded logic to the configuration and a couple days to build a UI on top.
Now engineers never touch tax rules ever again and deliver actual value in other domains. Your team remains small, possibly even shrinking as a result of your work.
But the Nth rewrite of $INTERNAL_LOGGING_FRAMEWORK has all kinds of sexy QPS, memory consumption, process time, etc. metrics to sell.
Right or wrong, I can say from experience the rewrite tends to get the promotion unless the tax guy writes a really compelling story in just the right way.
Humans are humans, be they managers or committee members.