There are multiple local attacker / evil maid scenarios, each require different counter-measures:

• Attacker with access to the system memory while the DB is unlocked, ie prior undetected compromise.
• Attacker with access to the system memory after the DB is locked, ie stealing a powered-on machine with a locked manager.
• Attacker with access to the system hibernation/swap file, ie stealing a power-down machine.

You’re focusing on the scenario #1, but the blog post allege KeePass is be vulnerable to all 3 attack scenarios. No password manager is resistant to #1 to my knowledge.

KeePassXC is at least partially resistant to #2 on a best-effort basis. Where possible, they use a custom allocator that zeros memory. The recent audit claim no username/password/passphrase was found in the memory dump after locking, but some metadata/notes were found. I think pass is resistant to #2 because it’s a short-live process that unlocks & obtain-the-pass & exit immediately.

IMHO #1 is a non-issue, #2 is a low-severity issue, and #3 is a medium-to-high-severity issue. Operating Systems have API programs can use to declare allocated memory as being non-swappable, which password managers should be leveraging to protect against #3. So being vulnerable to #3 is bad.