While I don't perceive Dotcom as a trustable character, his incentive to NOT store any encryption keys on the servers is much higher than any of his competitors.
Another service which is open source is Tarsnap[1]. It doesn't do syncing or have a free tier, but it's definitely trustable online storage.
In both of these cases the encryption keys are not on the servers.
An additional provider which claims to offer cloud storage/backup with zero-knowledge is Crashplan[3]. I wouldn't trust them as much as either of the previous options, but I still think they're telling the truth. I note it partly because I really like their approach. You can a) let them keep the key and thus you can still reset your password etc, b) let them keep the key so you don't have to transfer it manually to all crashplan-using computers, but have it encrypted on their end with a password only you know (can't be reset), or c) provide your own key which they claim they'll never know. These three tiers make sense and at each one you sacrifice some usability (such as the web-interface being unusable at (c) I think) in exchange for security.
So yeah, dropbox and google drive are both obviously able to look at your data, but that doesn't preclude using other cloud storage providers. There's many that are trustworthy and have the code to prove it. In the case of Mega, I'd trust them less than the typical one. They're big enough that the government will notice them... they'll need to make it usable (allow password resets etc), it looks like you upload unencrypted data and then they encrypt it server-side (edit: turns out it's client side javascript encryption. Downside there is it'll probably be a bit slow)... All of these are problems. If it's not sent already encrypted with a key they've never touched then the government could court-order them to alter the software to store unencrypted copies or to keep encryption keys. Since they're the one giving you the key they obviously know it at some point, however briefly, and they are thus vulnerable. Forcing users to generate and supply keys just isn't user-friendly on a web-only application. The only way you can make that work, as SpiderOak did, is have the user download an application which seamlessly does all the crypto work.
[0]: https://spideroak.com/ [1]: https://www.tarsnap.com/ [2]: http://support.crashplan.com/doku.php/articles/encryption_ke...
Wuala claim to be unable to access your files (https://www.wuala.com/en/learn/technology) (but who knows if they're lying?)
Not sure how these other companies operate, but unless the user hand-encrypts files with openssl, gpg, pgp, etc., then the trusted client software has the potential to be a vector for compromise.
The only protection against that is that the cloud storage provider doesn't have the encryption keys.
There are other reasons as well: potential vulnerabilities in their software, malicious/crazy/corrupted employees, etc. Healthy need-to-know rule is enough to decide that if there's no reason your cloud provider should have access to your data, he shouldn't have it.
Dropbox being a YC company means absolutely zero other than that YC liked their idea and supported them. That doesn't give me any assurance that they won't make a mistake or that an employee won't sell my data.
In fact, Dropbox, despite being a YC company, already slipped up majorly once to the point that every account was completely passwordless. You could just type in random emails at the web login and view some stranger's files. Story here: http://techcrunch.com/2011/06/20/dropbox-security-bug-made-p...
On the other hand, AES has yet to slip up. My AES encrypted data will take a significant fraction of the life of the universe to crack and, YC or no, a single programmer error won't break it.