Is there any reason for an alternative Bitcoin implementation to use Berkeley DB? The primary reason Bitcoin's C++ reference implementation uses Berkeley DB 4.8 seems to be backwards compatibility. It doesn't appear that BDB4.8 (or BDB at all for that matter) has any superior advantage over current-day alternatives like Redis or RocksDB, at least based on the limited research I've done (source). To the best of my knowledge, most alternative full-node implementations steer away from wallet support (source, source).
Performance benchmarks seem to indicate that there is no performance benefit to sticking to Berkeley DB (source) yet I cannot seem to see any widespread adoption of anything else except for recent introduction of SQLite support (source) for Bitcoin Core despite the growing pains of BDB4.8. I can't imagine any other reason as to why BDB wasn't dumped altogether if it wasn't for backwards support.
Is there any reason why alternatives like RocksDB (which supports at rest encryption though it isn't well documented), ArangoDB or Aerospike (all that seem to have existed at least five years ago) were not considered? Is there any security benefit to sticking with BDB? Any redeeming properties of BDB that make it a definitive choice over what is available currently?
Should a new implementation stick to BDB or use another library for wallet support and if so, what should it be?
Backwards compatibility is a massive priority for Core and it is generally very conservative in its technology choices. I don't think it would consider a new (database) technology until it had been proven over many years on other projects. It is providing a consensus engine and infrastructure and doesn't have the same tolerance as startups or bigger corporations for cycling through different options and experimentation if it is going to endanger backwards compatibility or require many developer hours to revamp shortly afterwards.