For GNUnet, we also need a particularly modern version of GnuTLS. Thus, it would anyway be necessary to recompile cURL for GNUnet. But what happens if one links cURL against this version of GnuTLS? Well, first one would install GnuTLS by hand in the system. Then, we build cURL. cURL will build against it just fine, but the linker will eventually complain bitterly. The reason is that cURL also links against a bunch of other system libraries (gssapi, ldap, ssh2, rtmp, krb5, sasl2, see discussion on obscure protocols above), which --- as they are part of the distribution --- were linked against an older version of GnuTLS. As a result, the same binary would be linked against two different versions of GnuTLS. That is typically a recipe for disaster. Thus, in order to avoid updating a dozen system libraries (and having two versions of those installed), it is necessary to disable all of those cURL features that GNUnet does not use, and there are many of those. For GNUnet, the more obscure protocols supported by cURL are close to dead code --- mostly harmless, but not useful. However, as some application may use one of those features, distributions are typically forced to enable all of those features, and thus including security issues that might arise from that code.
Ting-Yi