Not encrypting at rest seems like a huge oversight, given that your service most likely uses AWS S3 and it is dead simple to turn on encryption. I'm not sure anyone will trust you to store their log data without at least encrypting data at rest.
I know something of logs.
Speaking for requirements inside other's logging use cases is pointless given privacy needs vary from use case to use case. While your statement may be factual for some use cases, claiming it's "a huge oversight" is blanket blaming statement across all use cases and thus becomes worthless.
Besides, if you want search for things in the logs, things have to be kept hot and moving unencrypted. That means no at rest encrypted storage for near realtime search use cases.
I wish I had a stick I could hit people with to get them to stop creating double bind arguments. If you really want privacy for your logs, deal with them yourself on your own equipment. If you absolutely have no time to deal with your logs yourself, then get comfortable with privacy issues.
It's literally setting a policy on a bucket and a flag on object PUTs if you're not managing the keys yourself.