For my use case I'm not worried about the client's security (in fact, he's the one I'm interested in protecting the server from).
We probably are assuming very different tolerance thresholds on security. But even so, I don't think you can argue for any security advantages of typical implementations for a 50-page protocol when comparing them to a one-way simple GIF sender.
+1 rfb protocol is not complex and properly documented
It depends on what you compare it to. I meant complex in the context of the use case I have in mind. It certainly IS much more complex (and powerful) than a simple GIF creator. But if you only need a one-way, low quality stream, RFB is overkill.
The protocol is 50 pages long with pretty reasonable margins and it even has pictures: http://www.realvnc.com/docs/rfbproto.pdf
It is an afternoon read. Most desktop environments in Linux implement their own VNC server just because it isn't that complex and you can implement a subset of the protocol for a server anyway.
I imagine if there was a protocol flaw revealed (or even in the many implementations like libvncserver) it would be patched overnight. All of them support viewer-only mode. I like krfb, because by default it only uses access passes rather than a global password, so unless you give someone credentials of an access ticket nobody can login.
I bet an exploitation in the way gifs download and how http resolves file transfers in the dozens of implementations of both is much more likely to have an exploitable man in the middle or other mechanism to eavesdrop, if not take remote control.