Two reasons I can think of:

1. HTTP/2 was a 'new serialization' of the core HTTP data model. HTTP/3 is too, so since it was ratified it made sense to use HTTP/3 to keep things consistent. 2. QUIC still exists, but it's now the underlying framing/messaging protocol on top of UDP. I can imagine future internet protocols being developed on top of QUIC that don't need HTTP/3.

Yup. For example there's a draft proposal for DNS-over-QUIC: https://tools.ietf.org/id/draft-huitema-quic-dnsoquic-06.htm...

Well, why did we call it http/2 and not just keep the SPDY name?

Probably because it's easier to know what's being talked about if we keep the historical protocol name. If the submission title was "The status of QUIC" I wouldn't have remembered it had anything to do with HTTP.

You can use QUIC without HTTP/3. QUIC streams are just bidirectional Streams without HTTP semantics, and can therefore carry arbitrary data.

The HTTP mapping on top of QUIC is called HTTP/3.

The IETF is reserving the QUIC name for the underlying transport protocol, which has been separated from HTTP/3. Google's QUIC has them tightly coupled, so it's just "QUIC", whereas IETF QUIC is a general transport protocol (like TCP or SCTP, but technically implemented on top of UDP) for multi-stream connections, and HTTP/3 is a HTTP application protocol on top of QUIC.

Some rather muddled answers here, but it's simple enough: it's an (upcoming) IETF standard. The name makes clear that it's a proper standard, not an experiment run by one organisation.

Something similar happened with SPDY (Google's experiment) and HTTP/2 (IETF standard based on SPDY).

That would be like calling http/1 'tcp'.