The length of the freeze seems to be directly proportional to the length of time since the last animation played. That and the way that the very first frame of the animation is displayed before the freeze begins leads me to think that it's maybe caused by the plugin incrementing some internal time counter until it actually catches up with real time, or somesuch.
I have no idea why this affects me - my wife's machine with (almost) identical config is totally unaffected, for instance, and I've not found any other reports of it online. Furthermore, it's not the only Compiz weirdness that it seems that only my box suffers from, so I'm in no way laying the blame on Compiz here - it's just One Of Those Things(tm) as best I can tell.
Since I couldn't find a 'proper' solution and disabling animations by hand every time I was going to be away from the machine for a few hours was getting tedious, I knocked together a simple tool that would do it for me.
It's my hope that a future upgrade (I'm using Fedora 8 here, with no plans to upgrade until 10 is out) will 'magically' resolve this problem, but in the meantime this script at least allows me to avoid it.
Naturally, this means that you must have Compiz's Dbus plugin active and the python dbus library (dbus-python package in Fedora) installed.
If compiz is not running, or dies, is restarted, etc. then the script will 'cope' (i.e. it basically ignores all errors, but tries to do things in a sensible way).
To use the script, simply start it with your session. It doesn't handle any sort of session management, daemonise, demand kibbles'n'bits, or anysuch. Simple, crude, effective.