- All decryption happens in a given backend when it's sending data to the client
That is not what I think of as TDE. But upon review, it looks like I'm wrong, and the usual usage of TDE is for server-side-only encryption at-rest.
But when I'm asked about TDE, people are generally actually asking for data that's encrypted at rest and in transit, where the client driver is responsible for data encryption/decryption transparently to the application. The server is expected to be able to mark columns as encrypted, so it can report the column's true datatype while storing a bytea-like encrypted value for it instead. In this case the server does not know the column encryption/decryption key at all, and it cannot perform any operations on the data except for input and output.
Some people ask for indexable encrypted columns, but I tend to explain to them how impractical and inefficient that is. You can support hash indexes if you don't salt the encrypted data, but that greatly weakens the encryption by allowing attackers to use dictionary attacks and other brute force techniques efficiently. And you can't support b-tree > and < without very complex encryption schemes (https://en.wikipedia.org/wiki/Homomorphic_encryption).
I see quite a lot of demand for this column level driver-assisted encryption. I think it'd actually be quite simple for the PostgreSQL server to provide support for it too, since most of the work is done by the driver. But I won't go into the design here since this thread appears to be about encryption at rest only, fully server-side.