As soon as you make two requests, websockets win out in packet numbers alone
Discussion
Each thing fits own use case, there is no cure for everything. Web sockets aren’t good for websites in some cases as well. For example, page state and caching (move back/forwards) is usually turned off on pages with web sockets.
While I do agree that there's nuance for sure, in the case of what you're referring to it's just a lack of tooling. There's are SOME advantages (mostly in dev simplicity) to having stateless protocols such as HTTP, but the flexibility of reusing a socket can allow building much better (especially better performing) applications.
No matter what there's no case where back and forth HTTP is faster than WebSockets. The only exception would perhaps be extremely well optimized QUIC http servers with literally ideal data sizes (and even then WebTransport or WebRTC would beat QUIC)
I do web services for 20 years. Vast majority of use cases are simple stateless requests to different services/endpoints. Opening a web socket for each is not effective at all. Some services take advantage of utilizing web sockets from the ground up or for the fitting task, that is also the good case. But saying one thing should replace another makes no sense to me, at least for the projects I do.