I share your worry about trapping data in proprietary formats, but I don't really see how that is relevant for a backup service. The premise in backup is that you have a copy of the data - in that case, it's easy to switch service by simply dumping the other service. The data isn't trapped as long as you have it.
The same applies for synchronisation services - you have the data, so when switching services you only need to unlink the synchronized devices from the old service, and link them with the new one. Though in case the service uses revision history, you'll lose that in the process.
The case about switching clients but keeping the old provider is an interesting one, though. All of the backup/sync services seem to have their own custom client, and I don't know any providers that would be using an open source protocol either - but if there is one I'm interested in finding out too. However, the above point still applies - if there aren't currently any, but an open source, client-agnostic model appears later, you can switch to it later too.
Are there any real or de-facto standards for treating S3 as a filesystem? If so, what windows and mac clients support these standards?
I don't think any of the backup systems use S3 (or such) in a non-abstracted way - that is, what's stored is S3 in no way corresponds to the actual data structure of the backup. As far as I know, they have their own (possibly proprietary) ways to store the data, and simply distribute that into S3 in an abstracted way as "meaningless" data blobs. Though I might be wrong here, since I haven't done any research on this.