I acknowledge that curl allows any TLS version with HTTP/2. It does however usually require that you as a user select to go that route, meaning that you decided to do something differently. I don't see the harm in curl allowing this.

Also, TLS < 1.2 is destined to vanish from the internet soon enough, which might just be another reason why putting effort into enforcing this might not be worth it.

Yeah, I'm not suggesting that you ignore the --http2 flag if manually specified, just that the default behaviour should be standards compliant.
I'm not quite as hopeful that TLS < 1.2 will disappear in practice any time soon. These things seem to have an unbelievably long tail.

A further aspect of this is that if a server configured to only support TLS 1.1 improperly negotiates H/2 (e.g. as the latest version of nginx will) then curl will go along with it. Not sure what the "correct" behaviour here should be, given that the other side is misbehaving, but maybe a warning?
I was looking at this because of your comment "you decided to do something differently", so here, a totally normal curl not restricted to any particular version of TLS results in this non-compliant behaviour.
Even on a secondary connection to the server curl continues to improperly use H/2.

curl -ksv https://localhost:443 https://localhost:443
*   Trying 127.0.0.1:443...
* Connected to localhost (127.0.0.1) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* TLSv1.1 (IN), TLS handshake, Certificate (11):
* TLSv1.1 (IN), TLS handshake, Server key exchange (12):
* TLSv1.1 (IN), TLS handshake, Server finished (14):
* TLSv1.1 (OUT), TLS handshake, Client key exchange (16):
* TLSv1.1 (OUT), TLS change cipher, Change cipher spec (1):
* TLSv1.1 (OUT), TLS handshake, Finished (20):
* TLSv1.1 (IN), TLS handshake, Finished (20):
* SSL connection using TLSv1.1 / ECDHE-RSA-AES256-SHA
* ALPN, server accepted to use h2
* Server certificate:
*  subject: C=gb; O=Test; CN=localhost
*  start date: Jan 10 17:39:59 2022 GMT
*  expire date: Feb  9 17:39:59 2022 GMT
*  issuer: C=gb; O=Test; CN=Test Root CA
*  SSL certificate verify result: unable to get local issuer certificate (20), continuing anyway.
* Using HTTP2, server supports multiplexing
* Connection state changed (HTTP/2 confirmed)
* Copying HTTP/2 data in stream buffer to connection buffer after upgrade: len=0
* Using Stream ID: 1 (easy handle 0x56100f4842d0)
> GET / HTTP/2
> Host: localhost
> user-agent: curl/7.81.0
> accept: */*
>
* Connection state changed (MAX_CONCURRENT_STREAMS == 128)!
< HTTP/2 200
< server: nginx/1.21.5
< date: Mon, 10 Jan 2022 17:50:08 GMT
< content-type: text/html
< content-length: 13
< last-modified: Mon, 10 Jan 2022 15:40:31 GMT
< etag: "61dc536f-d"
< accept-ranges: bytes
<
Hello World!
* Connection #0 to host localhost left intact
* Found bundle for host localhost: 0x56100f47eaf0 [can multiplex]
* Re-using existing connection! (#0) with host localhost
* Connected to localhost (127.0.0.1) port 443 (#0)
* Using Stream ID: 3 (easy handle 0x56100f4aab90)
> GET / HTTP/2
> Host: localhost
> user-agent: curl/7.81.0
> accept: */*
>
< HTTP/2 200
< server: nginx/1.21.5
< date: Mon, 10 Jan 2022 17:50:08 GMT
< content-type: text/html
< content-length: 13
< last-modified: Mon, 10 Jan 2022 15:40:31 GMT
< etag: "61dc536f-d"
< accept-ranges: bytes
<
Hello World!
* Connection #0 to host localhost left intact

maybe a warning?

libcurl doesn't really have any warning system. It just has the verbose messages, and in a case like this libcurl is already talking a lot of verbose messages so saying "ALERT: HTTP/2 connection using < TLS 1.2" I doubt many users will care, if even notice at all. I would not object to such a line though. Perhaps that's even the best we can do about this.

We don't have any existing good ways to insist on TLS 1.2 for HTTP/2 in libcurl right now, as the protocols are fairly independent. We don't even know if HTTP/2 is going to be used until after the TLS handshake, so basically the only action we have would be to force-close such a connection and retry it again with a raised minimum TLS requirement. And if it negotiated TLS < 1.2 in the first place, chances are it will fail in a subsequent 1.2 attempt. Is that going to make anyone happier? I mean apart from perhaps someone reading the HTTP/2 spec and checking off compliance check-marks?

Maybe the best "fix" for now is to simply document that we don't enforce this requirement.

We could of course insist on using < HTTP/2 when TLS < 1.2 is asked for. Will this make any users happier?