Not sure about any specific use cases for this Mongo feature, but security requirements are often just checkboxes without much thought put behind them, or not valid in certain contexts, like SaaS/cloud.

Classic example is on-prem enterprises requiring data encryption at rest when moving to a cloud vendor. I can explain to a client that encrypting an S3 bucket with an AWS-managed key doesn't really prevent anything beyond someone physically stealing a hard drive from the AWS data center, and that the cloud provider can still see all of their data because they control the encryption key... or I can just click the "encrypt data" flag on the S3 bucket, make their security and compliance officer happy, and be done with it.

So, you're totally right, but this might be a case they needed to satisfy where an enterprise security team or regulatory agency said that they couldn't put X data field in the cloud unless it was encrypted, but X data field was really important to the application team.

Correct, a database feature can't prevent errant developers from posting customer credit card numbers on Twitter either, but compliance auditors won't accept "We don't bother encrypting data because it's pointless!" as an answer. The very real use case here is when private contracts between an end customer and a service provider says "You are in breach of this contract if load my data to any 3rd party service that has the ability to see my data, regardless of whether they use that ability or not. You are allowed to use that other service if you extend your audit program to also audit that other service provider according to my standards and report back to me." I've personally seen this situation prevent the use of SaaS. An encryption control like this where the 3rd party doesn't have keys to decrypt the data is considered satisfactory.