"Ease of use" is mentioned, and I suppose this refers to HTTP being text-based, pretty readable and intuitively understandable. HTTP/2 and later aren't like this anymore, for the sake of efficiency. It's a trade-off, but at this point I don't see much value in using it for APIs anymore. If you value efficiency and clean design, there are clearly better alternatives that aren't more complicated than what HTTP has become.
By "ease of use" they probably mean that the ecosystem is so advanced, one can easily write a HTTP handler in the language/framework of their choice.
In reality through, now days it's a nightmare to implement a HTTP server/client (at least for individual developer like myself). HTTP/1 is already a struggle by itself, HTTP/2 is much worse with all the new concepts & HPACK etc it added, and then you have HTTP/3 which introduces an entire UDP transport for you to implement. There is no easy part in HTTP if you choose this route.
WebSocket has a lot less fluff, but you could as well use a raw TCP socket and send JSON payloads over it with your own "protocol", e.g. with an op attribute for the action and an error attribute in responses. Another protocol that comes to mind is Apache Thrift.
