That's actually not correct, GIFs can encode the differences between frames and quite efficiently for screen recordings.
A GIF will be more efficient for a screen recording so long as there are small changes between frames.
The situations where GIF can be smaller or more efficient than real video codecs are generally esoteric, to the point where I’m happy to say that no one should ever use GIFs for block-level graphics.
So for example a moving pointer can be very efficient if the encoder is able to take advantage of all these features.
A better encoder can take the images from the article down by a lot (I got 80% reduction with minimal reduction in quality using https://compress-or-die.com).
Have a look at the following two encodings of the same screen recording from the article, compressed to the same file size and the same framerate: https://tempklasjdf.s3.eu-west-2.amazonaws.com/most-engaging... https://tempklasjdf.s3.eu-west-2.amazonaws.com/most-engaging...
To my eyes the GIF version preserves a little more of the sharpness of the text but there's not much between them. And GIFs are simple and intrinsically support looping.
As an aside, there is currently a proposal to bring some features from GIF (and a few additional ones) to HEVC to better support screen recordings: https://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.71...
Colour palettes and efficient spatial (rather than frequency domain) coding are being considered, both features of GIFs. Also support for RGB colour space rather than YUV420 to better preserve the colours (just like GIF!).