If that's the case that's a choice Google made. Windows via the CryptProtectData API[0] allows you to protect data via the user's session just like the Gnome Keyring/KDE Wallet.
But as you pointed out, another process with the same privileges can decrypt it making it pretty pointless in both cases. Only way to securely do it is to prompt the user for a decryption key each time they open the browser which has usability issues but Firefox offers it via the Master Password functionality.
Correct, Windows does not have per-application identities that could be used with a keychain service. Furthermore, every application in your Windows session (unless sandboxed) has access to virtual memory of other applications in the same session.
On macOS, applications address spaces are isolated and code signing certificates are used for identifying application requests to the keychain.
selinux can help in some of these situations (not saying it will necessarily in this case). Generally speaking, the browser context is not allowed to read user private data like ssh keys. However, since the browser context in this case needs to read passwords, it doesn't apply 1:1. You probably need a different context from the general browser context that can read password data.
But as you pointed out, another process with the same privileges can decrypt it making it pretty pointless in both cases. Only way to securely do it is to prompt the user for a decryption key each time they open the browser which has usability issues but Firefox offers it via the Master Password functionality.
[0] https://msdn.microsoft.com/en-us/library/windows/desktop/aa3...