With pure file encryption where the user's password serves as the key you lose...password recovery features, public links for files, shared folders, web access, mobile access (unless you want your phone doing the decryption)
All other syncing services do things a pretty similar way
This is wrong in several ways (as evidenced by other comments in the thread):
> public links for files
easily done by creating an unencrypted copy
> shared folders
you can do this by copying, encrypting with new keys for each shared user, and then sending notification of those keys to the user (via some side channel), and then deleting them on your end after they are accessed (you can re-encrypt with the accessor's keys at this point). You can do a bit better if you leave "half open" asymmetric channels (so you can store encrypted messages/keys only the recipient can decrypt), but that might be overkill.
> web access
you probably will need to use java (or NaCl) to do this, as javascript tends to be too slow to do asymmetric encryption (the the needed bignum support just isn't there). If you're willing to wait, it can be done in javascript in ~5 seconds on a desktop PC.
> mobile access
Uh, all modern smart phones can do encryption fast enough (well under a second).
> password recovery features
This is the only salient point. You can kind-of counter it by using the security questions to encrypt the actual encryption key a second time, so that the data can be decrypted if you answer the security questions. But that's obviously less secure.
All other syncing services do things a pretty similar way