The efficient processor they've chosen requires on the order of 20
microamps per megahertz at 1.8V to run code out of Flash, or 1.7 milliwatts of power. It draws only about 0.004 milliwatts in deep sleep, and takes less than a microsecond to enter and exit deep sleep.
Their energy-harvesting switches produce 0.33 milliwatt-seconds when pressed or released.
So you want to be efficient and enter deep sleep whenever possible. If you can have a duty cycle that looks like "Take sensor reading and run computation when button is pressed or when timer elapses, transmit over BLE, update e-ink display, or whatever our device does, then go back to sleep after 2 ms" that's easy - at even absurdly fast update rates of ~20 Hz, you're only using a 4% duty cycle and drawing an average of just 0.07 mW, requiring one button press every 10 seconds or so.
If you've got 3 button clicks per second, you can stay active all the time. But neither a 3 Hz button-press rate, nor a non-sleep-using firmware are reasonable. Of course, when you're bringing in a full ~10 mW of power continuously from the solar panels, the buttons are kind of a nice-to-have, you'd have to mash them at crazy rates to even equal the panels.
They're not even close to the potential efficiency of the processor - they're running an emulator for goodness' sake, which was almost certainly not designed with power saving in mind. If they started from the ground up reverse-engineering the Gameboy functions with the goal of maximizing power efficiency, yes, it's perfectly reasonable to assume that they could run continuously.