Be careful as there are two distincts problem.
First there is the “spectre” attack. The idea here is that you can use timing to detect wether some data is in the L1 cache or not, witohut actually accessing such data (so you can do it even when you don’t have access to the data). This can be used both inside a process (for example a javascript code in a webpage could access Firefox passwords), and with a tweak, between two different processes. This can affect all CPUs, no matter the instruction set or internal design. However, the attack needs to be specifically crafted for each application, and the fixes are also application-specific (ASLR helps, and there will probably be other similar counter-measures).
Then, in addition to that there is the “meltdown” attack. This uses largely the same idea, but because of an additional problem in intel (and, so far, only intel) CPUs, it can also be used from an userland application to directly access kernel data. This is the one that led to that large patch in Linux to unmap the kernel memory completely (not just read/write protect it) when userland code is running (which is a little costly - but newer Intel CPUs already provide a faster way to do this).
And yes, if we were to fix this we would probably implement a “4G/4G split” for 32-bit Haiku. Since the kernel and userland memory do not need to live side by side in memory anymore, we could as well have each of them allowed to use the full address space, which could help with porting Wine and would also allow apps to use more than 2GB of memory, a limitation we sometimes hit (for example if you open a lot of big/complex pages in Web+)