If you distribute and link libcurl v69 dynamically, the dynamic linker symbol table for your process will contain references to v69 symbols. If you then load an e.g. GL driver that in turn links libcurl v42, the GL driver will end up with some combination of v69 and maybe v42 symbols, despite being compiled against v42 headers containing v42 struct sizes and offsets.

Now there is an opportunity for silent memory corruption in your program, one that even once detected, which may not happen for years, cannot easily be fixed without completely rearchitecting the build.

When using a wide variety of system APIs including at least NSS and OpenGL, there is little control over what dynamic libraries end up loaded, the exact configuration will vary across machines

Substitute libcurl for libexpat or libX11 or libstdc++ and the principle continues to apply. I can't think of a good reason something like libcurl would be used by the Nvidia driver or some bizarro embedded board's GL driver, but that doesn't mean the Nvidia driver doesn't now or in the future link it, and if/when that day arrives, the problem lies entirely with the program that mixed random system deps with random self-compiled deps.