You are correct in saying that the main point of the blockchain architecture is decentralization and I understand why using the oracle method within such architecture might seems self-contradictory. However, if you want to move outside of the blockchain itself, the oracle method is the only way to do so — as you are moving from a decentralized structure to a centralized structure, you have to face some sort of centralization at one point or another: finding consensus in a decentralized network for a centralized data misses the point (misleading sense of trustlessness + not scalable + requires determistic datasource) and is not always viable.
As explained in the previous comment, the oracles network approach has some relevant pitfalls that the single oracle approach doesn’t have to face. That said, there are ways to reduce the trust into the single oracle, so that the centralized approach doesn’t compromise the blockchain model.
A very good introduction to the concept of blockchain oracles and the ways to minimize the trust in that regards can be found on the Bitcoin Wiki. Specifically, Oraclize leverages the “trusted hardware” and the “Amazon AWS oracle” approaches to trust minimization. This means that when using the Oraclize oracle service the trust in the operator (Oraclize) is reduced as it cannot compromise or tamper with data and pass unnoticed. This is the very idea behind the concept of authenticity proofs.
Thanks to authenticity proofs anybody at anytime can verify whether a data was altered or not during the delivery process — authenticity proofs are cryptographic proofs proving that the data delivered to the smart contract is indeed the one generated by the datasource (i.e. Web API). Oraclize provides authenticity proofs based on multiple technologies, so that smart contracts can choose between those or even decide to combine them, should they need stronger security. Besides, thanks to the Proof Shield you can verify the authenticity of data straight from within the smart contract — smart contracts can therefore decide to discard data, should the authenticity proof result invalid.
While having a centralized operator, the methods introduced above allow to reduce at a minimum level the trust involved (mostly on the availability, and not on the authenticity).
On a slightly different topic is the inherent trustline that needs to be opened with the data generator (i.e. Web API). An important point to note here is that the data generator doesn’t necessarily need to be the blockchain oracle. Specifically in our case, Oraclize provides the data-transport-layer only — the Web API generating the data is at this point the only trusted party and it is in fact chosen by the smart contract (not by Oraclize).
Your point of having the end-user/smart contract rating the source generating the data is indeed correct. However, this is not something exclusively related to smart contracts or to the blockchain as the Web APIs are usually general purpose. As an example you can consider a financial DApp using Yahoo Finance to retrieve the data you need — the source of data is limited neither to your smart contract nor to the blockchain context, it is therefore already valued/rated by other users.
As for the reputation system idea, while there might be multiple ways to implement it, that proposal is indeed interesting to evaluate the quality of data generated by each source. Oraclize doesn’t say anything around the quality of the data (by design), it only provides guarantees around the authenticity. By combining Oraclize’s oracle service and a reputation system for datasources, in case of “wrong” data you would be able to identify exactly where the issue came from — you could verify the genuinity of data thanks to authenticity proofs (therefore whether the issue arises from Oraclize) and, going further, the quality of data produced by the datasource (and eventually adjust its reputation accordingly). When some data is then reported to be bad, you could choose not to trust that datasource anymore, hence to just get authenticated data (via Oraclize) from the other datasources that, according to the reputation system, are still trustworthy.
Ultimately, the basic oracle method is indeed self-contradictory, still there are ways to mitigate that by minimising the trust.