Hey dub—
Here's the deal: a color lookup table, AKA a CLUT, is a device written into the header of an Indexed color mode image file as explicit color values, as a means for quickly displaying GIF images, which are by their nature, indexed. In other words, TIF images and such, which have a color cpability of 16.7 million colors, would be ridiculously large if they had a lookup table, so instead, they're keyed as implicit color values for every pixel. In contrast, Indexed color mode uses explicit color values in a very limited palette of 256 unique colors, maximum.
Your problem happened during the conversion from implicit to explicit values, where ImageReady had to "clamp" original color values to the limited color palette. Look at the blacks in the image on the layers. You'll notice that there's degrees of transparency surrounding the blacks; you intended areas to drop out, but Indexed images can have only one "don't show" color, while your original PSD file has several degrees of transparency.
When you told IR to Optimize, the program averaged the several degrees of transparency to a single one, several of whose colors were remapped to the Indexed color table incorrectly. When I reassigned a different color table, I increased the blacks and decreased the available whites, forcing ImageReady to move the colors you consider important to darker values.
A kludgy way to ensure that this doesn't happen in the future is to use the Pencil tool for creating GIF frames. You do this and because the Pencil tool doesn't anti-alias, there will be no partially transparent pixels and converting to Indexed GIFs becomes an either/or scenario. You could also try converting every frame's color mode in separate files to Indexed color (Image>Mode) to preview what potentially could go wrong. Then reassemble the file on layers and export.
BTW, I did write about this several versions ago

.
My Best,
Gare