Not everything can be neatly refactored out of a process.

Process boundaries don't protect against internal exploits, which is what most of the C and C++ exploits are all about.

If you are able to force a process to change its behaviour, the process boundaries become useless.

Process boundaries specifically protect against these exploits.

So how does a process boundary protect against Heartbleed?

Process boundaries help you when you start jumping through a ROP chain that spawns a shell because your process doesn't have access to things that it shouldn't, even when compromised. Calling Heartbleed an example of a process "changing its behavior" doesn't really make sense in the context of exploits that can cause arbitrary code execution.

You don't have to spawn a shell as a seperate process. Injecting and executing code inside a vulnerable process has been done for a long time.

A shell spawned in an unprivileged process is not very useful.

One doesn't need to spawn a shell.

Injecting and executing code inside an unprivileged process is not very useful.

Some black hats would consider stealing data, data corruption or triggering DOS already very useful for ransonware.

So each one gives an example that suits their own sales pitch.