One can reasonably conjecture, for example, that every function that encrypts data in 0.5 Core-2 cycles/byte is breakable.
This is wrong. OTP is below 0.5 cycles/byte, and as we know it's very secure. Now, the author probably meant proper encryption, like functions that actually take key that doesn't have to be longer or equal to message length.
Also, does 0.5 Core-2 cycles/byte mean that the algorithm take 2 cycles to encrypt a byte using 0.5 core?
There isn't such thing as 0.5core. Core 2 Duo is architecture of Intel processors, and this means that on such processor, you can encrypt 2 bytes of ciphertext per processor cycle (but keep in mind that operations on ciphertext are usually done on 16-byte blocks, so this means that you do 8 operations on ciphertext).
Is there a table or some paper that talks about the timings of algorithms in Core-Cycles/byte? I am guessing this is implementation dependent as well, though the algorithm design also sets lower bound on this.
It is implementation dependent, but authors usually give performance they were able to get using optimized implementation, and usually only include time it takes to execute some core function, without padding, key setup etc. Cycles/byte are usually calculated by measuring time it takes to execute algorithm, because for many years now, there isn't set time in which CPU operation finishes.
Again, its not obvious to me. Can someone explain these two sentences to me?
Well, to achieve avalanche effect, you have to mix data. And author assumed that you cannot do this in 5cycles/byte. But actually Chacha20, variant of Salsa optimized for modern CPU's instructions, seems to be able to get to about 3-4cycles/byte. See here