I was talking to jrmuizel about this not long ago, and he said we might be able to avoid much of the reflow / painting occurring in the content-deck if we stop animating the margins on it. We might be able to achieve the "shrink" effect in another way. For example, the customization palette container can default to 2em margin on the left and right, and have 2em-wide ::before and ::after pseudoelements on either side. The trick is to setting the z-index of those pseudoelements very low, and then using CSS transforms to translate the pseudoelements behind the container, creating the illusion that the container is shrinking. We'll need to do something special with the panel container and the menu panel as well - the panel container will need a 2em wide strip to suddenly "grow out" from the left side (in LTR mode), and the panel itself will need to translate 2em. But the good news is that pretty much all of this can get offloaded to the GPU, which means we skip a ton of work. Does this sound crazy?

Comments in IRC suggest that this approach might not be crazy. HOWEVER, a hacky proof-of-concept patch did not perform any better. That kind of surprised me. After some experimentation, I noticed that if I want for ~2s after the about:customizing tab opens before kicking off gCustomizeMode.enter(), the transition is considerably smoother than if I don't. This makes me suspect that the transition isn't intrinsically difficult or janky due to layout or painting, but is likely due to something that's occurring within that ~2s window on the main thread that normally occurs simultaneously with the animation. I'll open a bug to investigate what that something is. I'm going to keep this bug open for now, but it's looking a lot more like a WONTFIX.

I think this was a hail-mary that (at least at this point), we don't need to pursue.

This was as far as I got with this. It was mostly the start of a PoC.