I think that would be of little help if the faster, less-secure cores have access to the same memory system as the secure cores. If the JavaScript engine of your browser runs on the fast cores, and you're visiting a malicious website, then vulnerabilities due to speculative execution on the fast cores could still leak information that was written by the slow cores. And you really wouldn't want to run the JS engine on cores without caches and speculative execution, at least not for everyday browsing.

What problem are you trying to solve?

If you just want constant-time operations, you just need dedicated instructions. Maybe they run on dedicated cores, but that's an implementation detail. I think this is a good idea, and it feels like we're heading this way already, more or less.

If you want to address all of the vulnerabilities that have arisen, you need full isolation. As mentioned in a sibling comment, you can't share any memory or caches etc. Each "security core" would have to be fully isolated from every other core, including every other security core. And you also need to segregate out "sensitive" code and data from non-sensitive code and data. When all is said and done, I don't see how we're talking about anything less than scrapping all existing ISAs, and perhaps even von Neumann architecture itself. I'm sure there are some middle-ground solutions between where we are today and this extreme, but I think they're going to look more like TPM/Secure Enclave than special cores, and they're only going to partially address the vulnerabilities.

You don’t really need a security core with my proposal. By ensuring that kernel and userspace code run in completely different page table domains, it removes the possibility for a meltdown style attack precisely because the memory was mapped alongside userspace and relied on CPU protections to keep it secret (those protections got thwarted by speculative execution). It’s actually a software design flaw.