Libgd is a copy-paste library for shared widgets; back before Git and submodules, we used to have libegg. The idea is to use libgd to iterate over UI, API, and functionality; then, move things to GTK if there’s enough of a momentum.
I fail to see what Cairo has to do with libgd; additionally, security is a non-issue, unless you care about the fact that nobody has ever audited glib and GTK either.
It can be built as a shared library—and typically it is, if the application consumes it through introspection; but it’s yet another dependency, and since there’s no API stability guarantee, it’s easier to bundle it with your own application. Additionally, libgd allows you to build only the bits you need in your application, so the binary size does not balloon out of control.
Complicated things have complicated dependencies
Nevertheless it is not easy to figure out for what is this library and what that GD in name stands for
Problems with libgd IMO are that name is confusing and easy to make mistake like I did and already more than one project is using it causes that some memory for the code is wasted.
It stands for “gnome-documents”, as it was the first application to implement the design patterns in the Human Interface Guidelines for GNOME 3.
The cost is negligible at best compared to the rest of the application. As I said: applications only build the parts of libgd that they use.
Even the cost of code duplication is minimal, since everyone uses it as a Git submodule, so changes are usually done centrally.
The main cost is that the API is unstable, and that any change will end up impacting everyone using the library; ideally, the most used/stable classes should find their way into GTK, but:
GTK 3 is feature frozen, so no new widgets
GTK 4 is still in development, so no applications are porting to it
the HIG is still evolving, so libgd widgets may or may not change
At some point, when GTK 4 stabilises prior to release, people will start porting libgd to it, and see what can be moved into the toolkit.