What this then amounts to in practice is kind of the reverse: it’s coinholder governance with a potential key-holder veto. I’d be fine with that proposal.
The essential thing is that the implications of the model are spelled out in terms of the capabilities that exist. If a de-facto keyholder veto exists (which it will), then that shouldn’t be left unspecified. If a de-facto centralization / corruption / theft exists, then that should also be made an explicit part of the proposal.
One way to think about this is the same way we do about cryptographic engineering: write down the threats, and then explain why we do or do not think that they’re a problem.
EDIT:
The more I think about it, the more I think that a “coinholder approval, keyholder veto” model makes sense. Coinholders may not have sufficient context/expertise to judge a proposal; a keyholder veto means that requests for changes that are likely to be dangerous can be defended against. At the same time, the fact that coinholders are primarily in charge of approving a proposal aligns incentives better than grantees being able to approve their own disbursements.
Add to that a consensus-level rate-limiting/e-stop feature, and I think you have a pretty robust system.