For particular single environment DBA must be able to perform backup / restore with the same xtrabackup commands without regard whether encryption is enabled or not.

If backup is restored in different environment - some tweaks may be needed depending on source and destination configuration.

Thus original configuration for innodb-encrypt-log (and innodb-encrypt-tables) must be stored in backup-my.cnf and used during prepare by default.

Currently following scenarios are observed, which are incorrect when
a. innodb-encrypt-log is enabled in my.cnf, but not preserved in backup-my.cnf
b. xtrabackup --prepare doesn't look into global configuration in my.cnf, so generates logs without encryption (default innodb-encrypt-log is OFF).

SCENARIO A.
xtrabackup --copy-back restores logs without encryption in original environment. That means DBA must take extra - care and always provide corresponding innodb-encrypt-log to --prepare. (Which breaks rule above)

SCENARIO B.
xtrabackup --stats --datadir=/backupdir looks at global configuration in my.cnf and reports error "Redo log crypto: getting mysqld crypto key from key version failed".

SCENARIO C. (technically the same as A)
After --copy-back :
xtrabackup --stats --datadir=/datadir looks at global configuration in my.cnf and reports error "Redo log crypto: getting mysqld crypto key from key version failed", because logs are not encrypted

TLDR: To make sure that DBA may use the same xtrabackup commands in single particular environment without regard of encryption configuration - backup-my.cnf must preserve original values for innodb-encrypt-log, innodb-encrypt-tables and innodb-tablespaces-encryption