thank you for bringing up this interesting point.
You are correct in the fact that while using our appliances (engine machines), third parties still need to leverage something which is provided by Oraclize. This is a limitation due to hardware components that are needed for the service to be operated (and, specifically, produce authenticity proofs). Being our service based on a variety of specific hardware components, it is needed for any third party to go through either our own appliance or our cloud service (which still is delivered via Oraclize appliances that we host).
On the other side, the hardware components (and the relevant authenticity proofs) included in the Oraclize appliance are NOT produced by Oraclize. Those are manufactured and provided by a variety of tech companies (i.e. Intel, Qualcomm, Google, Ledger, etc). Moreover, those hardware components are specifically designed to support trusted computing, which is leveraged for the execution of the Oraclize service. This means that anybody can verify at any time what goes in and what comes out, while being able to verify that the entire process was executed as expected according to Intel, Qualcomm, Google, Ledger and/or the producer behind whatever other hardware component is included in the Oraclize appliance.
All the above ensures that the data-fetching (for example an API call) is done correctly with no tampering of data: there is no possibility for the operator of the machine to compromise its correct execution, if this happens then the authenticity proofs would be invalid (as the Trusted Execution Environments would need to be altered and the proofs wouldn’t get signed correctly).
I hope this helps. If you have any other question feel free to ask :)