Gated clocks are very bad.
Avoid using multiple clocks when you can (called clock domains).
Research and implement clock domain crossing when you can't.
Learn about synchronous clock domains(related clocks) and asynchronous clock domains.
Learn about meta-stability.
You are correct, it is highly recommended to use a single clock, and then pass enable signals around in your design to components that should be turned off or on conditionally, rather than gate the clock. You can also use an enable signal like you suggested to run a section at effectively a lower clock speed - more on that later.
The idea is to minimize the number of clock domains, and minimize the number of clock domain crossings. This absolutely holds true for ASICs just as it does for FPGAs, and even discrete logic circuits.
When all logic is performed with the same clock (with no clock gates) all the logic updates at the same time (with tiny bit of delay called clock skew)
This is great, because you can be sure that all inputs to all of your registers have been properly set up with enough time to be valid for the next clock, and you know all of the register outputs will be valid after the clock occurs. This is the basics of a synchronous design.
When you have two related events that occur on different clocks, even if they are closely related (like a register reading from another register, but from a gated clock) there is a risk that the data can be corrupted when it is transferred. This is called meta-stability.
If you need more than one clock, carefully define what needs to happen on each clock domain, and device what the communication requirements are. Do you need to send data in both directions, or do you only need to send data from the faster clock to the slower clock? Or maybe the slower clock to the faster one? How much data do I need to send, and how often should I send it?
There is a cross clock domain solution for each one of these cases, and each solution is slightly different. Fortunately, you don't need to re-invent the wheel (although you will probably need to re-write it)
FPGA 4 fun has a great intro to this: