You're right that unsophisticated malware may be thwarted by per-app disk encryption or credential stores like Keychain, but it doesn't represent a security boundary. That's why I would describe the Chrome team's approach as being "principled"--they're refusing to implement an ambiguously useful security feature because its bypass would not represent a bug.
Whether such a feature is nonetheless valuable for the user is unanswered by that discussion, however; as you say, it may have value in some circumstances.
However, remember that by volume most exploitation is (as best as I can tell) economic--people who do it for business. And people doing it for business can buy whatever malware is on the market. If stealing in-memory secrets is reliably accomplished (which it is), malware vendors have a strong incentive to implement this and sell it as well.
So I think you have the right idea, but answering the question is nontrivial. If Chrome implemented file encryption (or, more likely, used the platform APIs where available), would the engineering cost (and complexity--e.g. different behavior on different platforms) be counterbalanced by the increased cost imposed on malware authors? Or would one or two malware authors quickly adapt and malware prices/effectiveness would remain fairly static?
You get the point.