If you have situations where your "bunch of people with commit access" aren't sure if there's consensus then you don't have a consensus.
As to why you need it: Because unlike countries people have a real choice. All your language users are volunteers. (No "Seasteading" and "Freemen on the land" are not real choices). Not only can they freely choose another language instead of Python, they can fork Python and go make their own instead, or maintain the current code frozen in perpetuity.
Now, if there really is a 50:50 split between people who must have feature X and people who'll leave if feature X is added to Python, nothing you can do will solve that. So it's wrong to try to design your structures for that problem. More often there is a third way, and consensus helps you to be sure you found the third way.
Maybe, after they explain how great A is the core committers can bring the language users around on the idea of doing A. Maybe after spending more time considering why B is beloved of language users the core committers come around to B.
Perhaps most likely if the two conflict is that C is developed as both sides look for the best of both, what an excellent outcome.
And if not, then do neither A nor B
We regret our bad ideas at leisure. No need to bake those bad ideas into a programming language just because of a vague feeling that "we must do something" (and as the saying goes "this is something, so we must do this").
Rough consensus is what you need here.
Why?