Maybe Ian can spot something out of the ordinary in those scope shots. To my eye they look just fine.
If I had this thing here on my bench, I think I'd clip my scope probe on to Pin 11 for a while. I'd adjust the sweep rate and trigger to get a trace that looks like your scope shot and get it as rock steady as I possibly could. Then I'd just watch and wait for the display to flicker. If the scope trace jumps or loses sync or shows something less than 8 pulses in a row, coincident with the flicker, that would tend to confirm Ian's theory that the CPU is getting overburdened and is starting to "stutter". It might also be interesting to watch Pin 12 for a while and see if the time between pulses changes significantly when the display flickers.
Look into it later when the dust is clearing off the crater.
I had some flickering intermittently at the beginning when I was designing the clock, but adjusted the balance between the Wifi and the display management to give the Wifi a chance to step in during the time *between* digits or between impressions and that solved it for me (or at least seemed to).
Perhaps I will make the display handling interrupt driven - I need to investigate that. It should be possible with the ESP, which is pretty advanced for these sorts of features.
Just a quick update to this: I am working on a new firmware version with an event driven display update. I have managed to sketch out the important parts and will work on integrating it this week. I hope that this will solve the problems once and for all.
I have noticed that the IN-2 tubes are much more sensitive to flicker and am using these as the "canaries" for this probkem.