The way to "solve" this is well known. You build buffers between the CPU and the Memory, and then execute as much as possible out-of-order. And that's the purpose of L1, L2, and L3 caches: to provide this out-of-order code enough data to work (while the CPU is waiting on slow, slow main-memory).
However, contemporary RAM is not designed to coordinate with the CPU very well on this front, at least compared to designs like HMC (a type of "stacked RAM", a competitor to a GPU's HBM).
HMC is interesting because its a packet-based system. You tell the RAM a memory-address to access, but then the RAM may return that memory out-of-order compared to other requests !!!
After all: RAM also has physical "latency" issues. When a bank is open, it needs to close, incurring a tRAS, tCAS, and tRC delay. (A "hit" to the same bank would incur only a tCAS delay). If RAM could execute "out of order", then the memory-controller could allow more efficient orderings of memory.
Juggling which banks are open and closed has been traditionally a CPU's memory controller job. But communicating this information over a many-cm long PCB trace incurs latency. So it makes more sense to put this logic as close to the RAM as possible (speed of light, capacitance, inductance, etc. etc. slow down the signal).
Furthermore: since CPUs are incredible out-of-order machines already, it wouldn't be a major hassle to make the memory also out-of-order. I mean, yeah, its complicated, but its no different to what CPUs already do with L1, L2, and L3 caches (and the programming constructs built on top: Atomic Accesses and whatnot to control the effects of memory-reorderings).
I haven't heard of any major computer use HMC yet however. Only $10,000+ FPGAs on occasion. Still, there exists RAM today which can execute requests out-of-order. When this RAM becomes mainstream (if it ever becomes mainstream), I'd expect systems to be able to get much faster.