"key rotation" means that the thread reads tablespace page by page, decrypts pages that were encrypted with the old key and encrypts them with the new key. So it does encryption, yes. Also if there was no old key, this thread will encrypt the (previously not encrypted) tablespace. And if there is no new key, the thread will decrypt the (previously encrypted) tablespace.

And it can also do scrubbing.

What can it be renamed to? "Background page rewriting thread"?

But if there is no key rotation, and the value innodb_encryption_threads = 0, encryption itself will still be happening when requested (via a table option or innodb_encrypt_tables variable), right?
That's when the name becomes confusing.
Same way, scrubbing will not be happening if innodb_encryption_threads = 0, even though scrubbing seems to have its own group of options.
It's a bit less confusing than the first part, but still.

I'm terrible with names, variable names included, so I can't come up with a good one. Maybe we should ask somebody for a second/third/fourth etc. opinion?

If innodb_encryption_threads = 0 then encryption will still be happening for page writes — that is for new pages or when an existing page is updated. But existing tables with ENCRYPTED=DEFAULT won't automatically become encrypted when innodb_encrypt_tables enabled.

Sure, let's ask. Ian Gilfillan, Daniel Bartholomew — what do you think of that?

Key rotation and scrubbing seem to both be encryption-related operations that need to be managed, so my first thought is to rename it to innodb_encryption_management_threads but I'm not sure if that successfully encapsulates what this option does.

The way I see it, scrubbing is not really related to encryption. See https://mariadb.com/kb/en/mariadb/xtradb-innodb-data-scrubbing/