But I believe you're right in that those exploits are not as dangerous in a non-shared hosting scenario.
An attacker could carefully craft network packets to force the control flow of existing software to manipulate the CPU state. They could and then use the timing differences in network packets to read data out.
Would be painfully slow, but theoretically possible.
But if you're just running a local home system the chances of being targeted with such an unreliable attack are virtually zero.
I think that's the catch: it's the set of cases where someone can get code execution without being able to directly retrieve the targeted data, which is already pretty low, and where the best mitigation technique is to harden against these attacks rather than use a dedicated service (e.g. if you're using an HSM for crypto or have a dedicated SSL-offload box, you don't have to worry about keys being compromised when someone finds a bug in the much greater exposed surface area of your application).