The ONLY reason that nostr is not a REST API is because it is meant to be publish-subscribe.  You subscribe to a set of filters, and stay connected, and as matching events show up they are shuttled down that connection to your client.  With a REST API, the client would have to keep coming back, "polling" which would create periodic lookups on the relay even when nothing is happening.  Also, clients would need to make new connections to make new requests, which is a lot of overhead.  There are hacky ways to try to get REST APIs to stay connected and poll, but I'm not entirely sure they are reliable.

HTTP REST APIs are useful. @fiatjaf proposes one here https://github.com/nostr-protocol/nips/pull/1325  and there is a NIP for HTTP AUTH here https://github.com/nostr-protocol/nips/blob/master/98.md

IMHO the ideal transport would be WebTransport, but that is too new, and barring that Websockets is the next best choice.

The downside is that some people don't have as much knowledge of websocket libraries and their usage as they do of HTTP REST. But that is easily solvable.