It doesn't seem like it mostly because browsers (slowly) decode GIF as they (slowly) download it, and cache all uncompressed frames in RAM. They don't do the same for <video> tag, because they assume it's only for high-res, non-looping video.

• GIF data is huge. 15x-20x times larger for the same dimensions & quality than normal video codecs, and sheer amount of bytes to chew through eclipses any savings from it being slightly simpler.

• GIF's compression doesn't support any parallelism. Frames have to be processed bit by bit, frame after frame. Your multi-core CPU can use only a fraction of its speed when decoding. OTOH modern formats support parallelism on all levels - frames, tiles within frames, blocks, transforms. Modern CPUs can process these very effectively.

• In modern systems RAM is ridiculously slow relative to computing power available on the CPU locally. However, GIF's LZW is based on lookups in a dynamic dictionary, so not only you have just one CPU core process it, the core mostly spends time chasing pointers.

• There's no hardware acceleration for GIF. For newer codecs it's quite common and very power-efficient.

There's no technical reason (other than legacy code) stopping browser vendors from treating AV1 just like GIF, with all looping <img> glory. In fact, Safari already supports H.264 in <img>! It's faster in every way.