Everything that http://gfycat.com/about says about GIFs is also true of APNGs. For things that are actually video (i.e. not a pixel-precise hand-drawn three-frame 32-bit image loop), using a video codec is just better in every way.
I agree that for most uses of GIF nowadays, a video codec would be superior, but better in every way? What about decoder overhead? For certain sizes of GIF, the combination of GIF + GIF "codec" (a trivial XOR) will consume less memory than, say, h264 + h264 codec - in some cases far less. A modern video codec is not at all trivial, and also is optimised for filesize, not CPU load.
> For certain sizes of GIF, the combination of GIF + GIF "codec" (a trivial XOR) will consume less memory than, say, h264 + h264 codec - in some cases far less.
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.