You are thinking of a specific attack that uses the 2nd spectre vulnerability (poisoning of the indirect branch prediction) to attack the kernel. I'm sure in the following weeks other attacks to the kernel will appear that do not use the eBPF. The same vulnerability can be in principle be used to attack other processes. Still there are both software and firmware mitigations for this attack.
The real elephant in the room is the first spectre vulnerability (exploiting the normal jump predictor), which allows untrusted code (think JS) to read anything in the same process. Apparently most [1] CPUs are affected by this. There is currently no mitigation for this, other than rewriting applications to use separate address spaces, and even then, I think with carefully crafted inputs even that can be exploited.
[1] apparently simple, in-order cpus are not, but in principle there is no reason for the attack to work there as well.
edit: another possible mitigation for spectre v1 is converting all bound checks controlled by untrusted input to force non-speculation (via if-conversion). It is going to take a very long time to covert all applications (it might be easier for VMs and JITs).
1) Ryzen is absolutely vulnerable to Spectre, however desperately you don't want to think so. (I don't want it either; I just bought a Threadripper 1950X, after all)
2) If you actually think the eBPF JIT being turned off is going to save you and that Ryzen is magically immune because it's off: you're deluding yourself completely. Thinking eBPF is the key or whatever is a full misread of the actual vulnerability... Attacks never get worse, they only get better. You are guaranteed to see more exploits that do not leverage eBPF, but other components of the kernel to compose gadgets. Modern systems are millions of LOC; there's ample surface area for this to happen.
