Generally, using an application whitelist will not only restrict what apps the user can directly launch, but also what apps the whitelisted apps can launch (after all,
explorer.exe - the Windows graphical shell, which hosts the desktop, Start menu, taskbar, file browser, and so on - is itself just a process that launches other processes when told to do so). Also, hopefully you wouldn't allow a process to launch other processes if it could be used to launch arbitrary other processes (the way a shell can).
Also, application whitelisting is frequently combined with library whitelisting. After all, libraries also contain executable code. This makes it a lot harder - though not impossible - to inject malicious code into another process (since the usual way to do that is to dump a malicious library on the disk and get the process to load it).
If the attacker can compromise some process (like a browser or document reader) and get arbitrary code execution within it, they can do anything the process can do. Even if the process isn't allowed to launch arbitrary apps (because of whitelisting) it can probably use the debug APIs to take over running ones and achieve persistence (until you log off / reboot) that way. They can also read your files and transmit them to the attacker's computer, or launch network attacks against servers inside your firewall, or so on. If the attacker has code execution in one process, they don't need to launch another one (though it's usually more convenient to do so).
One solution to this is sandboxing, where you restrict what an at-risk process can do. Most desktop web browsers, Adobe Reader, and a growing suite of other software (including most things in the Windows or Mac App Stores) use sandboxing these days. A compromise is still bad - if somebody compromises your browser, for example, they can see what you're doing with that browser, and possibly steal information or hijack sessions that way - but they can't do things like attack other processes.