Really the way the governance process works is a series of vetos. None of the vetos stop the process from moving forward, but a group exercising their veto power makes it significantly harder for the process to move forward for others.
- First veto is the EIP editors, who can choose to not merge an EIP into draft.
- Second veto is the Core Devs group, who can choose to recommend against a change.
- Third veto is the client dev teams, who can choose not to implement a change.
- Fourth veto are economic participants, who can choose not to use a client that implements a change.
The process can be skipped/bypassed by anyone. As a user, I can fork a client, author a change, and then run a node containing that change I will have successfully hard forked with the change I desire, but it is unlikely that anyone would join me on my chain in this case. Thus, the veto powers at each step are weak at best.
The system has inertia as well. If something makes it all the way to implemented in clients, it has a lot of inertia and it is actually reasonably difficult to get the community to not move forward with that change. Similarly, if the Core Devs call results in agreement on a change, it would be hard for a single client to exercise their veto power (but they can certainly try).
I’m personally a fan of this mechanism for client development and protocol improvements. I think democracy and voting in general is a terrible process because the vast majority of voters are largely uninformed and vote with their heart, not their head (I have personally done this in the past as well, it is human nature). This process allows people who have spent a lot of time thinking about an issue the least amount of inertia pushing against them and those who have spent less time more inertia to fight against.