This is a question that I have been asking myself for a while and I have not found an answer.
Is it because of licensing issues? Because of the file format? Some other reason?
This is a question that I have been asking myself for a while and I have not found an answer.
Is it because of licensing issues? Because of the file format? Some other reason?
Just to prove the opposite: Direct embedding GIF is possible, admittedly not in PDF, yet in SVG output.
We just have to add a graphicx rule that treats GIF (static/animated) as another bitmap format (besides PNG and JPEG) with a user-provided <img file base name>.xbb file containing the bounding box information:
\DeclareGraphicsRule{.gif}{bitmap}{.xbb}{}
For a 480px * 360px image, the contents of the xbb file reads
%%BoundingBox: 0 0 480 360
For in-lining GIF data into the SVG output, the GIF file must be base64 encoded. Package media4svg provides a command for this that we make use of to modify the graphicx driver code for bitmaps (\Ginclude@bitmap).
(Requires pkg media4svg, v0.9 2022-08-12.)
Typeset example.tex listed below with
dvilualatex example
dvisvgm --zoom=-1 --bbox=papersize --font-format=woff2 example
or
latex --shell-escape example
dvisvgm --zoom=-1 --bbox=papersize --font-format=woff2 example
or even
xelatex --shell-escape --no-pdf example
dvisvgm --zoom=-1 --bbox=papersize --font-format=woff2 example.xdv
N.B. Firefox fails to play animated GIF embedded in SVG that is itself embedded in a web page (like TeX.SX). It looks like a bug. Use a Blink-based web browser instead, such as Chromium, Chrome, Opera or Edge. Or (right-)click on the image to open the SVG in a browser tab of its own. 
Input file example.tex.
(Download GIF from https://upload.wikimedia.org/wikipedia/commons/d/d3/Newtons_cradle_animation_book_2.gif)
\documentclass[dvisvgm]{article}
% download `Newtons_cradle_animation_book_2.gif' before typesetting:
%
% https://upload.wikimedia.org/wikipedia/commons/d/d3/Newtons_cradle_animation_book_2.gif
\usepackage[a6paper]{geometry}
\usepackage{graphicx}
\DeclareGraphicsRule{.gif}{bitmap}{.xbb}{}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% provide BoundingBox information in a separate .xbb file
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\begin{filecontents}[overwrite,noheader]{Newtons_cradle_animation_book_2.xbb}
%%BoundingBox: 0 0 480 360
\end{filecontents}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% patch graphics backend driver `dvisvgm.def' to physically embed
% bitmaps into DVI
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\makeatletter
\let\Ginclude@bitmapOrig\Ginclude@bitmap
\def\Ginclude@bitmap#1{%
\baseSixtyFour{#1}{72}{{?nl}}\bitmap@stream%
\Ginclude@bitmapOrig{%
data:image/\expandafter\remove@dot\Gin@ext;;base64,{?nl}%
\bitmap@stream}%
}
\def\remove@dot.#1;{#1}
\makeatother
\RequirePackage{media4svg} % provides base64-encode utility
\ExplSyntaxOn
\cs_new:Npn\baseSixtyFour#1#2#3#4{
\sys_if_engine_luatex:TF{
\xdef#4{\directlua{media4svg.base64("#1",#2,"#3")}}
}{
\msvg_convert_file_to_blob:nnnN{#1}{#2}{#3}#4
}
}
\ExplSyntaxOff
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\begin{document}
\section{Animated GIF}
\noindent\includegraphics[width=\linewidth]{Newtons_cradle_animation_book_2.gif}
\end{document}
There is an article in TUGboat from 1996 (written by by Keith Reckdahl) that includes a discussion of supporting image formats. The article is from Volume 17 No. 1 and is called Using EPS Graphics in LATEX2ε Documents Part 1. The discussion is centered around dvips, but a similar argument can be made for direct pdf output (see David's comment on this question). Also the historical practise of not implementing direct support in dvips may have influenced choices made for pdflatex and later compilers.
Quote (page 52-53):
10.3 Including Non-EPS Graphic Files
While it is easy to insert EPS graphics into LATEX documents, it is not as straightforward to insert non-EPS graphics (GIF, TIFF, JPEG, PICT, etc.).
[...]
10.3.1 Direct Support for Non-EPS Graphics
It is often requested that LATEX and dvips support the direct inclusion of non-EPS graphic formats, making it as easy as inserting EPS files. While this would be convenient, there unfortunately are some problems which complicate things.
For example, most non-EPS graphic formats use binary files which cannot be read by TEX, which prevents LATEX from determining the size of the non-EPS graphics. Furthermore, supporting non-EPS graphics would also require dvips to incorporate graphics conversion capabilities (GIF-to-PS, TIFF-to-PS, etc.). This would not only require a lot of programming, it would also require more maintenance in the future.
Rather than directly incorporating graphics conversion routines, dvips provides a mechanism of calling external conversion programs. This mechanism can be accessed from LATEX by use [of] the command argument of \DeclareGraphicsRule. This has the benefit of being more flexible than direct support, and since it keeps the graphics conversion uncoupled from the DVI-to-PS conversion, users are free to choose their own graphics conversion program.
Another interesting historical approach is described in an article from 1991, where photos in GIF format are converted into a font (!) for direct inclusion into LaTeX documents.