I'd prefer not to mess with the clock. If I'm using a chip like the 8 bit register 74HC377 which has a LE (latch enable) and clock then I can bring LE high to disable the input to the latch.

But what if I'm using 74HC574 which is also an 8 bit register which is similar to the 74377 but swaps the LE for OE (output enable). If I need control over whether data is clocked into this chip then the only option left to me is to gate the clock.

One of the main things to avoid with clock gating is the problem of creating spurious clock signals. Whether there is a risk of this depends on the method taken for the gating and the relative timing of the raw clock versus the other signals with which you are gating the raw clock.

Whilst a spurious clock may or may not be a problem when latching it is more likely to cause an issue with a counter, such as in the program counter or within a microcode circuit's timing. Having the counter advance unexpectedly and with an extremely short duty cycle would likely cause a malfunction including violating timing constraints of other components within the overal circuit.

A common case is where the clock is ANDed with some other control signal - I need to do exactly this in a register file I'm designing because I'm using 74HC574 which doesn't have a LE input. I need the 74HC574 for it's tristate output which means I need to compromise on the clock gating. It a question of reducing the complexity. But now I'm worried about gating effects. A spurious clock might make me latch the wrong value. Surely an AND of a control signal and the clock won't cause a problem?

The paper A Review of Clock Gating Techniques covers a few of the approaches to clock gating and the first option discussed is a "simple" AND gated approach. The paper demonstrates how the relative timing aspect can cause spurious triggers.

However in the paper I wondered whether the analysis was correct, whether a hazard had been missed. Below I've highlighted the transition I'm concerned about in this extract.

It seems to me that there is a risk that this transition might cause a spurious clock on Gclk. This might happen if the en went high moments before the fall of the raw clk. Whether or not this potential glitch occurs in practice depends on the derivation of the en. In a CPU the en signal might be generated from some combinatorial logic and is likely to lag the clk due to propagation delays, in which case the problem I'm concerned about wouldn't happen. 

The paper same paper goes on to criticise NOR and also other techniques - worth reading.

Timing matters.