The feature is there for paperwork reasons.
I still put my seat-belt on, even though there's an airbag in the car.
Think about your risk model: there are a lot of employees at your cloud provider, and a lot of high-profile customers. There's a defense in depth approach here. Metal detectors, security guards, and searches to enter & exit data centers. Data encrypted when on-disk. Keep the keys in some KMS system. Physically isolate the KMS system, use HSMs, restrict permissions to the KMS.
Without these measures, you might end up with a system where ordinary customer support representatives, software engineers, data center technicians, or system administrators / SREs can exfiltrate customer data on a whim. At a large cloud provider like Amazon, Google, or Microsoft, that's not a small attack surface. That's a lot of people. The idea is to make it extremely hard for one of these employees to exfiltrate customer data without somehow leaving a record of it which ultimately gets the employee fired and prosecuted.
Customers will make mistakes too--screw up their permissions, fail to encrypt their data, or whatever. The idea behind defense in depth is that any one security measure can probably be circumvented, but multiple independent security measures are harder to circumvent.
It's really easy to be cynical about security but I have worked at cloud providers and the threats are real.
A combination of the default policy being poor on all AWS services, the shared responsibility model of AWS delegating this risk to clients and the default security posture in the industry being terrible makes the real problem of solving this like traipsing across a field covered in poo.
An analogy; you have to tick the box to put your front door key under the doormat. The burglar knows where the hole in your fence is and knows you might keep your keys under the door mat. Plus your kids left their keys on the github bus.
Of course the SOC2 audit says you ticked the box and you tell everyone your house is a castle.
I am not really sure its better than nothing - what it does do imo, is muddy the waters a bit for casual users, and perhaps make it seem like the customer doesn't really need to do as much securing themselves - because it is now 'encrypted by default' - giving a false sense of security - and as others have pointed out, really just protects against extremely rare edge case problems, i.e. the lost hard disk.
Another often overlooked benefit of at-rest encryption is that it can enable crypto-shredding; delete the object key and the object can no longer be recovered. That's faster, more efficient, and better for the environment compared to other kinds of "secure erasure". Of course if you want robust crypto-shredding you do have to take some care about where the keys might be cached and for how long, but you can't do it without encryption at-rest.
* Lost/stolen hard disks from AWS datacenter
* Attacker or rogue AWS employee who has access to low level storage but not keys.
The article is correct that this misses many important situations but it is still better than nothing.