Making CPython faster

I don't think that is the case. The hardware designers managed to handle architectural state (registers, memory) correctly in various implementations of speculative execution: They buffer changes to that state in internal buffers (e.g., in the store buffer) until the instruction is no longer speculative, and then commit these changes to permanently-visible architectural state. For microarchitectural state such as caches, they changed the state already speculatively, because, after all, it's not architectural: from an architectural correctness point of view, it does not matter if the cache contains the permanent value of one memory location, or the permanent value of a different memory location.

It's only when you consider side channels that it makes a difference, and apparently they had not thought about that; and apparently before 2017 nobody else has thought about that either. So you might say that side channels are hard to reason about.

Or maybe it's because few people tend to think about side channels: On the software side we knew mitigation techniques for a number of side channels for non-speculatively executed code, and they are so arduous that we use them only for secret-key handling code. On the hardware side, cache side channels have been known for a long time, but we do not want to do without the speed advantage that caches give us, so hardware designers design caches and leave it to software people to use mitigations; however, there have been other side channels (IIRC due to resource constraints) that have been eliminated in more recent hardware with a different balance of resources; my dim memory says that the Ivy Bridge was affected and Haswell was not, but I may be misremembering. It's not clear whether that was an intentional or accidental fix.