Why wouldn't someone decide to encrypt all the fields using Salesforce Shield?
There's a number of limitations, outlined in General Shield Platform Encryption Considerations. This includes a limited ability to use MIN/MAX/COUNT_DISTINCT, WHERE filters, GROUP BY filters, ORDER BY clauses, etc. In general, you're giving up a lot of functionality just to have encrypted data. You only want to use it when local regulations require such encryption, because it causes significant penalties.
The reason to use shield fundamentally comes down to how much the regulation and contractual obligations of a given Salesforce customer allow them to trust the already in-built security mechanisms of Salesforce.
- All traffic is already transmitted under a secure connection
- All users are required to be authorized prior to accessing a given Salesforce tenant
- CRUD permissions configurations exist to ensure the right user can do the right things with certain classes of data
- Sharing is in-built to ensure certain records can remain private to rank-and-file users
- Field permissions exist to ensure that the right users can access the right fields
- Loads of other security settings including password policies, network IP white listing, time-based login settings, 2FA, and much more
- Direct DB access is completely abstracted from developers making it impossible to one tenant to access another tenant's data
- DB level partitioning and sharding
- Data centers themselves undergo rigorous security vetting
If after that, a customer feels that none of those things will solve their regulatory/contractual obligations, then, at that point, platform encryption is probably worth looking into.
However, you should only encrypt the bits of data that require protection, and there are limits to the field types that support it. So you could never encrypt all fields. But it is designed to cover the surface area of data that is most likely to contain sensitive data requiring compliance.