The fact that HTTP 1.1 speeds are even comparable, let alone faster in some situations, should at least tip the scale in its favor.
How much do you understand about gzip or brotili? How much do you know about TLS? Do you understand all of the functionality of TCP? Network congestion and checksuming?
QUIC includes compression, encryption, and transport into the standard which is why it's more complicated. Just because Http 1.1 doesn't include those parts explicitly into the standard, doesn't mean they are unused.
Http 1.1 is only "easy" because it sits atop a sea of complexity that rarely faces the same critiques as Quic does.
Do you understand how to build TCP packets by hand? A lot of the confusion between QUIC and HTTP/3 is intentional because it is somewhat merging the layers that used to be entirely separate.
All the examples elsewhere of "I can telnet/netcat to an HTTP/1.1 server and mostly do the thing" avoid the obvious fact that telnet/netcat is still doing all the work of splitting the messages into TCP packets and following TCP rules.
Presumably QUIC and HTTP/3 are separate enough to still warrant the idea of a telnet/netcat for QUIC taking care of the low level details and then you could try to write HTTP/3 on top of those apps a little easier, in a similar fashion. Though maybe not, without the rich history of telnet-related protocols on top of TCP and HTTP/3 still currently the only protocol targeting QUIC today.
Are these realistic web browsing scenarios? Because that seems false. For most websites http/2 is a pretty significant performance win.
HTTP/3 is actually not super complex. The main trickiness comes from header compression. But unlike HTTP/2 the stateful QPACK compression part in HTTP/3 can actually be deactivated, and just the stateless static dictionary and huffmann compression being used.