HTTP is in a similar sorry state. For example, it offers pipelining support but nobody can reliably use it because it probably won't work on some forgotten about machine somewhere on the path.
The project needs some other work, since it looks like changes to Chrome have broken the mouse tracking. [0]
The perfect use case for pipelining is when the client is connected to a (reverse) proxy near to it, is making retryable requests, the origin is far from the proxy, and the requests don't take much time for the origin to process.
You can also get benefits if there is a proxy near the server and the requests take significant time to process, but the proxy can divide them over multiple servers (or the server handles pipelining and divides over multiple threads).
The way these usecases are met instead is through multiple TCP connections, or multiple multiplexed streams in HTTP/2 (and beyond). There's certainly benefits of individual streams, but there's costs too, so it's unfortunate that the http/1.1 way was stiffled.
HTTP pipelining isn't largely unimplemented because people were lazy - its largely unimplemented because its easy to DOS a server, possibly by accident, and there are significant latency issues due to head-of-line blocking with slow requests.