iOS is of course a very different story and some localhost macOS bugs might have parallels in iOS (not this one though).
This is untrue for iOS, because iOS actually does have a pretty robust security model which has only-semi-trusted apps running on your skeleton key to everything.
More fundamentally, an unsandboxed process can do things like set environment variables, update config files, modify applications installed into the user's home directory, read your browser cookies, etc. as a consequence of traditional desktop apps having unrestricted access to the user's home directory, so preventing reading memory doesn't really prevent one app from attacking another.
Perhaps I'm also completely misinformed or misunderstanding what GP is saying but each process is meant to get it's own virtual address space
Windows: https://docs.microsoft.com/en-us/windows/desktop/api/memorya...
macOS (Mach): https://developer.apple.com/documentation/kernel/1402405-mac...
Linux: /proc/*/mem or http://man7.org/linux/man-pages/man2/process_vm_readv.2.html
and so forth.
As an aside, any app that triggers gratuitous keychain prompts (I’m looking at you, Skype and Outlook for mac) is a weapon of mass-miseducation. People should think long and hard before authorizing keychain access; if you keep firing prompts at them, they’ll end up clicking/tapping without reading what it’s for, which is a recipe for phishing.
I don't think it's that hard: it's basically equivalent to finding the value of a variable in a coredump, which is a thing I've done a lot and which debuggers explicitly help you with, even if it's a release build without debug symbols. One way to do it is to inject a controlled password into the same build of the program on your own machine, dump its memory, search for the password, and then reverse ASLR if needed (which is easy if you have full memory read/write access; the point of ASLR is to make limited-access vulnerabilities like small stack overflows hard to exploit, but sort of by definition the information about where libraries are is located somewhere in the process so that the process itself can run). You can then script doing the same thing once per current-ish release build per current-ish OS, and get a robust automated attack.
In general I think people overestimate the difficulty of doing clever things with process memory (one of my favorites here is the "Vudo" exploit from 2001 http://phrack.org/issues/57/8.html in which sudo could be tricked into temporarily writing a 0 byte one past the end of a buffer and then restoring the original byte, and it's still exploitable to get root). If you haven't done it yourself, it sounds harder than it is, and betting that it's hard because it sounds complicated when there's no actual isolation boundary is more-or-less security by obscurity.
The same thing applies to triggering keychain prompts: use a side channel (e.g., polling the stack of a legitimate process) to figure out when the user is likely to need a keychain unlock, then trigger a keychain unlock for your app at the same time. (Note that you can either pop up a dialog on your own or actually request keychain access for your own process.) You also might not even need to time it: just rely on the fact that the vast majority of users are going to respond to security prompts in a way that appears to unblock their jobs, without evaluating whether the prompt is reasonable. See studies on click-through rates of cert warnings before they got hard to click through, the continued effectiveness of phishing / spear-phishing, etc. If you pop up a dialog saying "Java Updater needs your password," I bet you'll get a ton of people who don't even have Java installed type in their password.
You probably have all the locally available data you could want. You may not have access to passwords, or other data that comes from actively using an online site which doesn't currently have active credentials (because they time them out or the user logged out previously). For example, depending on the person and the documents they keep locally, you might not have access to any banking information.
Privilege escalation opens up a whole slew of capabilities that make it much easier to achieve that, not to mention allowing a rootkit to get access back immediately after a reboot.
Local account exploits are like a burgler breaking in (even repeatedly) while you aren't home. Privilege escalation is like them installing a remote camera system and recording your every action while you are home. Both are pretty horrible, but certain things are much more likely to be exposed with active monitoring of what you are doing over extended periods...
So tell me kind sir: what OS do you use?
As opposed to what other operating system? Even Linux with SELINUX allows that...
Of course, it's a different matter for shared computers in school computer labs. Or if mac servers were a thing.
Some kind of embedded/industrial control system? z/OS?