In most currently widely-used E2EE systems isn't the provider in control of the client anyway, and thus there's not really any protection against rogue employees? If I'm in control of the client and I'm encrypting all my data before I send it to the cloud storage provider, then sure, I'm safe against rogue employees at the provider accessing my data (although they could still delete it). But the E2EE systems I'm aware of consist of a provider distributing a client that promises to encrypt data between that client and the provider's servers, but not in a way that makes the process easily auditable by the customer.
I don't know how you do things where you work. But a rogue employ making changes to the product, then wide releasing it or releasing it to anybody is not something you can just do.
And if you did somebody would quickly notice and you might go to prison.
That a pretty high barrier to entry compared to just having admin access on the db.
Of course I'm not suggesting that service providers shouldn't have robust processes to protect against rogue employees. What I'm suggesting is that from the customer's perspective, if you're running a client that was distributed to you from the provider, you should be just as worried about a rogue employee putting something malicious in that client to e.g. compromise the E2EE as you are worried about a rogue employee reading your unencrypted data on the server.