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. nostr:npub180cvv07tjdrrgpa0j7j7tmnyl2yr6yr7l8j4s3evf6u64th6gkwsyjh6w6 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.