Example 1: You have a group of people who care deeply about performance, reliability, maintainability, and long-term health of the code base. You have another group of people who care deeply about user experience, development velocity, and pushing features to market quickly. In an open allocation system these two mindsets will self-organize into different teams, and will avoid working on each others' projects. The former group will find that the latter are cowboys who throw together messes that they then have to clean up. The latter will find that the former are slow killjoys who result in mediocre products delivered late. The latter group will get to market first, which makes the former believe they're marginalized and gets most of them to quit the company. When the product inevitably starts creaking at the seams, there will be nobody around to fix it and introduce robust development processes.

In a formal org, these would likely be two job functions (call them "SRE" and "SWE", or "Infrastructure" and "Features", say) who are forced by upper management to work on the same codebase. Disagreements between them become explicit negotiations where all the technical issues and trade-offs are laid on the table, and then people can come to an agreement after looking at all the considerations.

Example 2: You have a brilliant developer who is terrible at working with other people and doesn't particularly want to deal with them. In an open-allocation world, he will end up shunned; nobody will want to work with him. In a managed org, it's often possible for his manager to pick off a certain really difficult technical challenge, have him go off and find a solution, and then interface with the rest of the group via some technical API.

Example 3: You have a technical lead who can't let go of the technical aspects, and insists on taking all the most interesting work for himself. In an open-allocation world, nobody will want to work with him, which means that he won't be a tech lead for very long, and eventually he'll probably get frustrated and leave. A manager could gently explain to him that taking all the most interesting work is incompatible with being a team lead, and have him choose one or the other.

Example 4: You have a project where consistency is the whole benefit of the project. For example, you're doing a company-wide visual redesign to make the company's product offerings more consistent for users, or you're introducing a language styleguide, or you're defining standard APIs for communication between components. These efforts typically never succeed unless they have top-down support from a strong leader. Everybody sees the need to agree on a standard, but when it comes to deciding what that standard is, everybody has their own agenda and nobody has authority to decide in favor of one alternative or the other.

Standards committees are good public examples of this: officially, it's "open allocation" where every company and member of the public who wants a voice has one, but unofficially they're dominated by the actions of people who can afford to implement and bring to market a concrete solution.