Interesting, so their augment is essentially that the memory-safety provided by the use of a memory-managed language is more valuable to them from a security standpoint than the memory scrubbing capabilities afforded by a lower-level language?
As someone in that thread pointed out, I would say that the onus should be on the OS SDK to provide memory management primitives specifically for the purpose of security that can be zeroed out after use.
They also point out that the threat profile is someone who can read your system memory when 1P is locked (serious compromise already), but is unable to read it when it's unlocked (otherwise why bother reading it when locked), which is a pretty small set of use cases.
I can think of at least one situation where that would be the threat profile: someone steals your laptop.
Not a super common scenario, but not exactly unheard of either.
1- User uses the laptop and logs into 1P successfully then locks it. 2- Hacker steals the laptop and uses it without a reboot. 3- Hacker hacks the windows/mac os password to logon. 4- Hacker dumps process memory for 1P.
For me, they would have to steal it while I'm actively using it. When I go away from my desk, I enable the screensaver which A) requires my Mac login password to unlock and B) locks 1Password, requiring the master password to unlock.
In 1Password 6, the Prefrences > Security settings include Auto-lock: on sleep, when screen saver is activated, when main window is closed, when fast user switching, when computer is idle for X minutes. I use all but "when main window is closed." It's much less of a nuisance since I started using Touch ID to unlock 1Password.
I haven't looked into them in a while but there is 3rd party software than can automatically enable a system's screen saver when a particular Bluetooth device is out of range (e.g. a smartphone, a smartwatch, etc.) which would help even more.