In my case, I've actually figured out the specific action (on my part) that causes the CPU spike/growing file issue. I've also (much to my own surprise) figured out how to resolve the issue and bring the file back down to its normal size.
OK, so the short version goes like this:
It all started when I attempted to update some customer process maps with a new, more vibrant orange. The "old" orange (already existing in the file) was like this:
The "new" orange (which is used across all new versions of our print and web collateral) is like this:
U.S. Web Coated (SWOP) v2
Also of note, all the fills as existed in the original file(s) were linear gradients, but with the start and end colors both matching the RGB values above (I didn't create these original files -- I would have ensured solid fills.) When changing the color to the CMYK values, I also changed to solid fills.
Now, for reasons known only to the tiny nanoengineered gerbils at the heart of OmniGraffle that make it do its magic, upon changing the color fills of objects embedded within a group, I can watch the Autosave file balloon to 10 times the size of the original file.
That's the other thing: The 100% CPU spike happens when the Autosave function triggers after I've changed the colors.
Now here's the really bizarre part: I can go back into a file that's been saved with the new color (and that has subsequently grown unmanageable in size) and change the color back to the original RGB color, and when I save, the file is back to normal and OGP returns to its former snappy performance.
How weird is that?
I haven't figured out yet whether the issue starts when changing color spaces from RGB to CMYK, or what. I'd like to be able to use the new color, but not at the expense of being unable to work due to the CPU spiking every time the Autosave triggers.
Anyway, that's what I've figured out.