Specifically, with my question I want to target Oracelize.it as arguably the most "state of the art" oracle service. This specification is done in order to exclude trivial attacks in the potential answer.
One potential attack vector is on the OraclizeAddrResolver. Essentially, Oraclize stores, on the Blockchain, the address of their latest Oracle contract. They also contain the power to change this address. An attacker, which could be Oraclize.it or someone who compromises their server, could trivially attack anyone using Oraclize by updating the Oracle address to the address of a malicious contract.
There are lots of ways you could go at an oracle service but if contracts are working on the Oraclize model where you're just taking data from some other website, the other option is to attack that website instead. When you build an oracle service you have some idea of the kind of target it could become so you can at least try to secure it appropriately. Whereas if you're running a weather data feed it probably doesn't cross your mind that people will potentially be using it to direct significant amounts of anonymous online cash.
The danger here doesn't even stop at the site that gets attacked, because once one feed gets attacked the other ones are going to start revoking API keys and bolting down their terms of service rather than go to the trouble and expense of making them secure enough for these purposes, and people relying on their results to settle their contracts are going to be SOL. This is one of the reasons why we designed Reality Keys with a potential layer of human intervention between the original data feed and the contract, rather than just saying "Here's what the data source told us, good luck".