"What is more, the encryption keys can be held on office thin clients that transparently download the decryption engine and keys from an onsite server which likewise can serve both to remote users as part of their login script."
This would be a great architecture for a business when talking only about accessing data that is shared among employees.
However, if they want to share certain files with another business to remotely access the encrypted data, then you have to also share the encryption key to support client side decryption, and you encounter the same problem as before. There are certainly businesses that have moved the majority of their data storage to the cloud, but there are a greater number who haven't made that kind of commitment, and only use cloud storage for sharing certain files/data with business partners. You could host a local server that retrieves the data from the cloud, decrypts it using the onsite stored keys, and serves it to authenticated business partners. This would mean deploying onsite the your own implementation of a web API or website that provides the interface for third parties to login and access authorized data. Half the reason to move to the cloud is to avoid implementing, deploying, and managing this kind of infrastructure.
And of course for individuals sharing with other individuals, this approach doesn't work either.
Essentially, as even your example demonstrates, somewhere a central system must orchestrate access and decrypt the data or provide keys to clients. Moving that system onsite mitigates risk by putting it in your control and affording the business the opportunity to legally challenge information/search requests, but it also decreases the benefits of using the cloud since you've now moved a major piece of infrastructure back onsite.