Thank you very much. I'm looking into it!

Thank you! AVX-512 appears to be a promising avenue towards improvement. I've found intel-ipsec-mb (https://github.com/intel/intel-ipsec-mb/tree/main) which I'll try to delve into. I'll sidestep using Python for this entirely as well.

Should anyone wish to undertake this migration, I am willing to provide funding.
Once completed, it will be made open source for the benefit of others (...although I hope no one else finds themselves in my predicament).

Thank you for your input. I might have used the incorrect term "optimized version"...
When reviewing KdfRomix::DeriveKey_OneIter(), as one example, it appears to me that removing memory allocations per iteration might be relevant when running lots of repeated iterations https://github.com/etotheipi/BitcoinArmory/blob/2a6fc5355bb0c6fe26e387ccba30a5baafe8cd98/cppForSwig/EncryptionUtils.cpp#L212

If the nature of Armory's algorithm means that threading doesn't scale past the number of CPUs, then the solution may not lie in encryption code "optimizations". On the other hand, if there's significant CPU idle time due to I/O operations, etc., might a high-memory system with a custom implementation offer some advantages? Sadly, I don't have the necessary knowledge to explore this deeper or implement the needed modifications.
So I guess this post is to figure out if I should look for outsourcing to analyze and improve the code, or if there's no point in going down that path.

It is indeed. My .wallet has a parameter of 32MiB memory with several iterations. I am well familiar with btcrecover and have been running it for a while now. However, I am only able to reach about 25 passwords per second. I do have most of the contents of the phrase, but I probably either mistyped a part of it when entering it in Armory or didn't document it correctly...
I created a Python script that generates all the passwords I wish to check into a file, but with 25 P/s, it will take years. I was hoping to reach 1000 P/s, which would make a great difference. Also, I'm willing to invest in more relevant hardware, once I understand what that entails.

I am looking to have an optimized version of Bitcoin Armory's encryption implementation re-written, aiming to efficiently recover a lost password. From my understanding, the algorithms used are designed to resist GPU-based attacks.
Is it possible to devise an implementation that leverages a setup with abundant RAM?

I came across some performance tests documentation for yescrypt, which utilizes a server with hundreds of GiB of RAM, preallocations of huge pages, etc.
https://github.com/openwall/yescrypt/blob/main/PERFORMANCE

Can a similar approach be taken to parallelize password attempts for Armory's wallet?

Thank you