I think you're answering in good faith but I find that caveat so overwhelming that it makes the point meaningless: if malware runs locally outside of a sandbox, you're screwed – full stop, end of story.
There are scenarios where master passwords are extremely useful and that's passive file disclosure such as a network home directory, a compromise of another account while you're not logged in, or – particularly relevant these days – a breached cloud sync service. I would make the case for that reason rather than as a malware resistance measure.
The long term fix requires architectural changes: none of the attacks described work directly on Mac OS X because the Keychain decoding happens in the securityd process which runs as root so the malware would trigger a confirmation prompt for each password it tried to pilfer. Unfortunately, this is also less than perfect as most users check the “Always allow” box granting permission to their browser for unprompted access…
There are scenarios where master passwords are extremely useful and that's passive file disclosure such as a network home directory, a compromise of another account while you're not logged in, or – particularly relevant these days – a breached cloud sync service. I would make the case for that reason rather than as a malware resistance measure.
The long term fix requires architectural changes: none of the attacks described work directly on Mac OS X because the Keychain decoding happens in the securityd process which runs as root so the malware would trigger a confirmation prompt for each password it tried to pilfer. Unfortunately, this is also less than perfect as most users check the “Always allow” box granting permission to their browser for unprompted access…