If you have 100k people who've opened e.g. websocket connections to your backend, I doubt you're going to structure things as a 100k-socket connection pool open to your backend. You've probably either:
A. got that scaled across at least 100 backend servers, even if those servers' CPUs are almost entirely idle; or
B. have chosen a completely different, extremely roundabout architecture involving client async requests with HTTP 202 responses + client polling of a "status of server-side promises" endpoint; or
C. are effectively manually doing what HTTP2 does automatically, by having a "stateful-connection load-balancer server" (e.g. SocksJS) that mediates between long-lived client connections, and short-lived RPC requests with async responses from your backend.
Whereas, with HTTP2, that could very easily be one machine, taking in those 100k nearly-idle connections, and passing them over one TCP socket to one backend.
This is true, however this limitation just increases the size of the connection tool needed for the same concurrency. I'm not saying HTTP/2 isn't better, I'm saying its less better for middleware than end user connection optimization.