Sorry. I went to bed. I'll frame the basic argument for Chrome and then show how it expands to other systems.
Chrome:
=======
Someone who can access chrome://settings/password is presumed to have physical access to your powered-on, unlocked machine. E.g. someone who sits at your keyboard when you get up for coffee.
And that person can just as easily install a Chrome extension that sniffs your passwords or steal your raw auth cookies directly from the developer console. (He could even paste some JS into the developer console to intercept the password as-typed by autocomplete!)
(Note that an attacker with access to a locked/powered-off machine or with no local access is not part of the threat model, since they are presumed to be addressed by FDE, screen locks, remote access controls, etc.)
Now, the major counterargument is essentially that a lot of unsophisticated attackers (like spouses) may not know about cookie jars or JavaScript, but they know about "view saved passwords." I find this argument somewhat reasonable, but from some vantage point it's security theater--not knowing about ctrl+j isn't a strong security guarantee, after all. So I view the Chrome team's stance as being a very principled one, namely: don't invest in "security" features where a bypass would not be a bug.
(In some literature this is referred to as a "security boundary", typically defined as "a control which, if bypassed, has a bug." Note the contrast with, for example, spam filters and antivirus, which may be sometimes bypassed while working as intended.)
More generally:
===============
I think what was lacking in this conversation in general was a firmly defined threat model and a firmly defined security boundary. My contention about per-application encryption is that it doesn't represent a security boundary because any attacker who can execute code that can read application-ACL'ed data on disk is by definition either running code at a higher security level (e.g. has root) or is running code at the same security level (and can thus inject code into the browser process itself).
This conversation gets a little more complex when talking about mobile OSes that have per-application sandboxing, but the same observation effectively holds.
Anyway, I'm tired of typing, but hopefully that makes a bit of sense. Let me know if I'm being confusing.