I presume what is meant is that it can handle a redraw fast enough to be in the next frame. In which case the answer is: all of them. Drawing text is not the bottleneck for a GUI program, unless you have a god awful browser stack as your rendering engine.
What are you supposed to do instead? Zed uses the GPU. It's not making calls to retained-mode widgets to individually reposition them, nor is it blitting into a buffer using the CPU. It's using the GPU which eats pixels for breakfast. You've been able to rerender the entire screen each frame for over a decade - just look at Windows 7 Aero, which ran on the laptops of 2009 for the exact same reason: it used the GPU!
Hadn't heard of that before, but it makes sense now you mention it. :)
Oops, thanks for the correction.
> Under no circumstance would zed actually be drawing 120 frames each second, right?
It does this when scrolling for sure. That's a trivial case where 120 FPS is required on a 120Hz display.
It also does this even when nothing on the screen is changing, but only for about 1 second after the last user input. This is explained in a blog post[0].
Now this does cause more power usage, because when Zed does not do this, the display can actually downclock to save power. But downclocking like that increases latency, which is why they prevent it from happening in the middle of user input (but still allow it to happen betwen each burst of input).