[derefr]

It's the image-hosting ecosystem. An animated image format needs to be accepted for upload by public image-hosts; it needs to keep its animated-image semantics when hotlinked and displayed "raw" by a browser; and it needs, needs to work when hotlink-embedded inside an <img src=""> element.

These are all things that are true of GIFs, and aren't true of any other video format. (And this doesn't even address the fact that many people use GIFs for the combination of animation and transparency, which <video> doesn't currently offer.)

The image-hosting ecosystem also naturally deals with the bandwidth-drain issue: image-hosts don't want their bandwidth stolen either, so they have a cap on upload sizes. By allowing just <img src=""> embedding, you naturally lean on the image-hosting ecosystem's bandwidth economics to protect your users.

By allowing arbitrary <video> embedding, though, you invite the nascent video-hosting ecosystem, which has achieved a different balance: far looser bandwidth limits, but far stricter caps on concurrent requests (e.g. the Dropbox-Public-folder model.)