You misunderstand, it should not be centralized under any development team. There should be many developer teams with many competing implementations of Bitcoin this is where the decentralization of development should lie.
It is interesting that you say we can not crowd source engineering decisions. If that is the case then it would make sense that different implementations of Bitcoin have their own internal decision making processes, and some like XT would decide on having a "benevolent dictator" so to speak. I believe this is rather common throughout open source projects. The consensus and the choice lies with the miners, the economic majority and the users in terms of the code they choose to run. This is how Bitcoin can remain free and decentralized.
Should? So what? How do you enforce it? We already have several implementations, and where are they?
Development skills are a scarce resource, and having multiple 'competing' implementations is actually wasteful. In a sense, Bitcoin Core is a kind of natural monopoly, because only this way it can attract sufficient expertise, and thus be robust and stable.
Maintaining a fork of Core code is actually much easier than maintaining different implementations, and XT, when it appeared, was OK -- it did implement some client-side BIPs that didn't make it into Core. It only became controversial when it started pushing changes to the protocol.
If you mean many competing versions of Bitcoin
protocol, that's a completely different domain.
Having multiple 'competing' implementations is indeed wasteful. So is sending every transaction to every full node on the network. The point is that decentralization is wasteful and very inefficient. However the cost of decentralization is worth paying because of the benefits it brings.
Bitcoin would become more robust and stable once such competition and decentralization exists within development. Having multiple 'competing' clients would most likely eventually lead to having competing versions of the Bitcoin protocol this might be unavoidable. I do hope that this block size debate will not cause a split but future issues might justify this however. Increasing the supply of Bitcoin for instance in the future might cause a split, I would not support such a change. However for people that really believe in inflationary economics as opposed to the deflationary model of Bitcoin this might make sense for them. One of the beautiful things about Bitcoin at least is that there would be no tyranny of the majority since people can choose what side of the fork they wish to support for themselves.
Quite the contrary, actually. More implementations, as they are diverting resources, mean lower quality of peer-review. This has already been
demonstrated in case of btcd, where it could've forked because of a sublte bug in opcode handling. Jeez, even Core, despite extensive peer-review, has forked in the past because of code bugs!
Bitcoin is consensus-critical, so you can't apply the same principles to it as you would to other open-source projects.
As for "having competing versions of the Bitcoin protocol" -- this won't work. How do you enforce network consensus then?
Bitcoin is not about the tyranny of the majority. It's about tyranny of the protocol. Rules have to be enforced for the network to function.
Still, development decentralization is orthogonal to network decentralization. I believe (my sig) that generally decentralization is best measured by cost of creating a new instance of something, not by an amount of existing instances. In this case, creating a new instance of Bitcoin implementation is low (nearly free if it's a fork of existing code). This way, development is already decentralized. The hardest part is convincing the community that what you propose is good. XT failed at that, and rightfully so.