I don't buy the argument about stealing bandwidth. A 50MB GIF is just as much of a bandwidth leech as a 50MB MP4.
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.)
Memory, maybe. But CPU?
I keep this snippet[1] at hand at all times, because pages with multiple animated GIFs peg my CPU and make my fan spin up for as long as they're open (even when they're in hidden tabs! even when the GIFs are scrolled off the screen!) This doesn't happen with <video> elements.
I think the problem is that web browsers never bothered to move GIF decoding/rendering/compositing to the GPU. It's especially bad if a GIF is animating while it has CSS image-scaling applied to it, which leads me to believe that--since the GIF "codec" must be re-applied on each frame--the browser doesn't cache the decoded frames, and thus can't cache the scaled decoded frames.
People don't really want GIFs; what people want are filesize-limited, auto-playing-but-only-while-visible, auto-looping, and silent-by-default videos. Let's call these "animated images."
The problem is thus: you're designing a piece of forum software, and you're considering whether to allow people to embed various elements in their posts.
There's problems with allowing people to embed arbitrary videos: they can steal bandwidth, slow the browser to a crawl, make sudden noises, play to completion while the tab is in the background, etc.
But if you allow people to embed static images, then there's no additional consideration required in allowing them to embed animated images. Wherever a static image works, an animated one works.
Right now, there are two ways to allow people to embed animated images: either you allow .gif as an image upload format, and then display it without processing--or you allow videos, but do quite a bit of server-side processing (of the kind Vine and Facebook do) to make the result into an animated image.
If there was an adapter format -- some simple file format that:
1. referred to a video by URL (maybe it could be an HTML5 document whose root is a <video> element?), which would then be embedded in place of the metafile;
2. whose media type fell under the image/* hierarchy;
3. and for which the browser would automatically enforce "animated image" semantics,
then that format would be a perfect replacement for GIFs.