I don't agree that encryption will inevitably be broken. That's a straw-man argument. If you're really worried about encryption, nobody said you had to use a standard encryption algorithm like AES-256. You could use a 512-bit or 1024 bit AES if you like. If you're worried about quantum attacks you can use a quantum-resistant encryption scheme. Heck, you can use 10 different quantum algorithms and 10 classical algorithms strung together.

I never said anything about encrypting anyway - the data could be non-sensitive data. It could be hashes or timestamps. If it is encrypted data, then it's really no more risky than storing it in the cloud. In fact it's a trade-off. If you store your data in the cloud you run the risk of them losing your data or confiscating it. When it comes to encryption you have 2 choices with the cloud: they manage the keys, or you manage the keys. Of course you can do both and double-encrypt your data.

The bottom line is: you need to take care of your own keys. If they get compromised, either through a physical attack or cyber attack, the attacker will be able to access your data whether you store it on a private cloud or on a public blockchain. So the issue comes down to key management. There are several ways to do this, most notably key distribution so there are multiple keys in different physical locations.

The bottom line is: If you are a law firm, and you have sensitive data, any time you need to access that data, you need to grab the encrypted data from somewhere, decrypt it, then view it, or do whatever you need to do. Whether that somewhere is a public blockchain or private cloud is irrelevant, so long as you're using a decent encryption scheme. It's just transferring bytes which are absolutely useless to anybody not in possession of the keys and with knowledge of the encryption scheme.