Data transfer between FFs in a CPU
Not necessarily. Bonus points for knowing that an input to an FF has as setup and hold time specification, by the way. 

But for many designs of FF the hold time can be 0 ns, i.e. you don't need to hold the data for ANY time after the clock edge. (When designing the FF, you can guarantee this - just make sure you use slower transistors or longer wires on the input, and faster on the clock!) 

Now the clock latches the data, but that process takes some time - called propagation delay, or clock-output delay - and then the wire to the next FF adds some delay of its own. So the next FF doesn't see its input changing until AFTER this time, certainly greater than 0 ns, so this is safe. (If it isn't greater than the actual hold time you ARE in trouble!)

The setup time is less important at this stage; since the previous FF output changes just after the clock edge, it has almost a whole cycle to get here.
Calculate clock cycle time - clock-output delay - wire delay - setup time and if the number is positive, that's safe too.

Setup time matters when you start adding gates or long wires between FFs; these add more delay. So when that sum becomes zero, the clock is too fast!

(There is another aspect; clock pulses arrive at different FFs at different times; for an accurate calculation you need to account for this "clock skew" in both setup and hold time calculations).

So you're not wrong; these are real issues but they have solutions. And chip design involves a LOT of these calculations (mostly automated by the tools, in FPGA design) - called "static timing analysis".