Consider the case where you have some data that you want to latch into a register under some particular conditions:
Here you would assert the gate signal whenever you want to save the data from flip-flop D1 into flip-flop D2 (maybe the D2 is a read buffer or part of a shift register, and a read transaction was just detected).
However, meanwhile the input data to D1 may be changing.
The clock signal to the D1 happens pretty much as soon as the clock generator produces a rising edge. D2, however, doesn't see the clock edge until sometime later, due to the propagation delay through the AND gate.
If D1's state has changed, then D2 might latch in the new data, rather than old data you expected from your RTL simulation. Worse, depending on the clock-to-Q delay of D1 , the AND gate delay, and the flip-flop hold time, D2's input may be in the middle of changing when it detects the clock signal rising edge, causing its output to go metastable.
If, instead, you use a flip-flop with a clock-enable input,
you won't have this problem. Assuming the flip-flops have zero hold time (typical within FPGA's), there's no extra delay for the clock reaching D2, and the two flip-flops will sense the clock edge at (darn near) the same time. Then D2 will always see the "old" data from D1 as your RTL simulation led you to expect, and won't have a problem with metastability.
You should really use (timer) interrupt driven firmware to ensure your clock ticks accurately. Software delays will cause a gradual drift because of variations in your program flow. Here is a good overview of how to use Timers on the Arduino platform. You can follow something like the pattern described in the section on "Blinking LED with timer overflow interrupt". The Arduino's 16MHz crystal is plenty accurate for a toy clock project if you write the software correctly.
This style of writing software is "event-driven," so you have to get your mind around that first. The hardware tells you something happened (in this case a second has passed) and your software reacts to it. Instead of you telling your software to "wait a second" and then doing something.
Best Answer
Find a CMOS manual for what you need to learn and avoid.
Look for rules on Switch pull-up debounce, Decoupling cap, Shoot-thru and ESD awareness.
It won't work without Pullup R's on the Switches. 10K or 100k or so. BCD THumbwheel switches are handier than toggle switches or DIP switches.