Using RESTORE instead of other commands to re-create data when rewriting the AOF it is possible, at the cost of exposing the internal RDB encoding (exposed anyway with DUMP / RESTORE), to improve the space efficiency, CPU usage, and write speed of the AOF in a significant way.

Probably this should be optional so that it is simple to turn it off (even with CONFIG) in order to create a more cross-version compatible or simpler to parse AOF.

I'm assigning this to myself as I prefer to write this core stuff myself.

Note however that RESTORE includes the RDB version inside the encoded data, so we don't have just this opaque blog of data. Redis versions not capable of loading encoded data will perform properly. Moreover we'll always make sure that the next version of Redis will be able to read the previous RDB file version (we always did it this way).

When to use RESTORE

Ideally we should use RESTORE all the times data is stored in a specially-encoded way, that is, we already have data encoded in binary form without additional work to do. This is the case of small hashes, sets, sorted sets, and lists.