For the most part it's not common to be able to make a server call curl with an arbitrary server which is usually required to exploit this sort of thing. There will be some vulnerable apps, but the vast majority of servers with this vulnerability present won't be exploitable in any practical sense.
You have to consider the author of curl has recently been vocal against CVE scoring for vulnerabilities that require very specific conditions or user stupidity to trigger. For him to come out with "the one rated HIGH is probably the worst curl security flaw in a long time" most likely means it's bad.
Hmm. The worst case I can think of is if the vulnerability is exploitable before (or during) verification of TLS certificates for http(s).
That would mean that someone in a MITM position would be able to inject the payload when libcurl make requests.
But even that seems less messy than log4j? It can't possibly be as common that libcurl makes connections to arbitrary user entered urls, compared to log4j logging user entered text.
I thought so at first but then I remembered server side request forgery, SSRF
That's a bug class that is quite common but rarely leads to code exec or other issues (except in some cloud environments). If this is something that gives code exec after pointing curl at a malicious server it's going to be bad.