System credential managers are the established way to do this properly. They are user configurable, generally maintain credentials in a separate security context, derive a strong key from the user logon credential, can more easily support hardware security mechanisms, and introduce minimum user friction by default. That's why Chrome and most browsers prefer the system credential managers when available (on Linux: libsecret, Gnome Keyring, or KWallet).

The application specific "master password" is more of an anti-pattern for effective credential storage. The most glaring issue is that user friction is so high that it's rarely ever enabled, because it's just too inconvenient and confusing for most people. But beyond that it has the weaknesses typical to any credential manager not deeply integrated into the OS (e.g. credential management is handled entirely in the user's context, management is inconsistent between applications, etc.).

I don't get the advantage of system credential managers - at least as long as the user is logged on, I can always hook myself into a browser process and retrieve the passwords.

The only advantage system-level password storage has is when the attacker e.g. wants to get the passwords from a forensic image or such.

You can use unique password stored in the protected system storage (like OS X Keychain) so at least user is protected from non-root users.

shouldn't that protection already exist just in the file permissions of the cookie storage?

this doesn't really protect much from other users since other users don't have access to the file in the first place, and doesn't protect from the user that owns the browser process.

which is probably why the bug still exists, adding a randomly generated key only adds another easily passable obstacle

I have user vbezhenar. I run browser under that user. I have system storage for sensitive data. Its data available only via API which checks permissions. E.g. only Chrome can access its data.

Chrome must be able to read its cookies, so cookies file must be readable/writeable for user vbezhenar. And there are high chances that I'll run malware program under this user vbezhenar too, so it can read cookies file, but it won't be able to access encryption password.

File permissions can be bypassed by anyone who gets physical access once, encryption can't.