The author doesn't appear to distinguish between a decentralised client and a decentralised specification.
The authors of the official Bitcoin client have de-facto control over the specification, so the design of the Bitcoin protocol is effectively centralised. I don't think anyone sees this as a problem, because if people start disagreeing they can always fork the protocol.
If a flaw is discovered in Bitcoin that requires a protocol change, I doubt we'll see any fragmentation. People fork projects over a wide range of reasons, but rarely over essential security patches.
This misrepresents the tight interlock between client and specification.
Suppose that there is a flaw discovered in Bitcoin that requires a protocol change. In a classic software system, the worst you'd have to worry about is a backwards incompatible protocol change; Bitcoin is designed with very little wriggle room in this respect. But furthermore, with Bitcoin, you have to worry about a change which existing Bitcoin clients will reject: for example, if you wanted to increase the reward given to miners.
You can fork the protocol, but you can't fork the economy. This is true in normal projects, and doubly true for Bitcoin.
I'm not sure I understand your point. Yes, in order for a Bitcoin fork to succeed, you'd have to convince the majority of clients to use the new protocol. However, once you gained a majority, the Bitcoins generated by the old protocol would fall in value relative to the Bitcoins generated with the new protocol. If your Bitcoins are worth $100 using the new protocol, but only $50 using the old protocol, there's a strong financial incentive to start using the new client so you can sell your bitcoins at a higher rate and to a larger audience.
Yes, it's centralised (to a degree), but when people talk about decentralised protocols, they usually mean that the protocol itself is decentralised. There's still usually an official or de-facto standard maintained by a relatively small group of people.
Your argument that Bitcoin is not decentralised could easily be applied to any P2P protocol. I don't think there's any P2P system around, except perhaps natural language, which has a decentralised specification.
The authors of the official Bitcoin client have de-facto control over the specification, so the design of the Bitcoin protocol is effectively centralised. I don't think anyone sees this as a problem, because if people start disagreeing they can always fork the protocol.
If a flaw is discovered in Bitcoin that requires a protocol change, I doubt we'll see any fragmentation. People fork projects over a wide range of reasons, but rarely over essential security patches.