There is a reality of running code on other peoples hardware: they impose limitations on network traffic that you cannot change. Example: Home-grade routers do NAT, but have table limitations which make it hard to have multiple connections. The connections get dropped, and users complain, not realizing it was due to them having bought a cheap router. Other actors in the network path between the client and the server impose their own limitations, making it hard to have multiple connections. (corporate firewalls being another big one).
HTTP/2 is a compromise, admitting that it is not possible to go fix or replace all this hardware. I worked on a few HTTP/2 implementations, and the complexity it incurs is significantly less than the alternatives.
And not only mobile, same applies for server-server connections over near perfect, inter-dc connections.
Even gigabit, and above links drop packets... because it's how TCP is supposed to work!
The higher is the speed, the more aggressive curve will be used by the congestion control algorithm.
In other words it will hit drops fast, be in the drop zone for longer, and this will be recurring more frequently than on slower links.
In fact, faster congestion protocols for speeds above 500 mbps get their speed by having A LOT MORE drops, not less.
Any protocol designed for the TCP transport must have been designed to work in concert TCP mechanics, not fight, or try to workaround it.
This is a perfect example of how AB test vodoo lead people down the rabbit hole.