The issue is a REST service is not ideal as clients are already connected to at least one websocket. And the POW can take seconds to return a result. Since websockets make sense, using the auth NIP made sense too - as clients already support it (or will soon).
The idea was it can be run independently from a relays or a relay could enable the POW command optionally - using a supported nip in their server info.
Relays are the closest next step for events that have had POW/signed.. so it made sense to keep them together or very close.
The POW nip already explains the basics to add POW, so this was more of a NIP for a provider that had opinionated design.
There is also a growing dependency graph of NiPs that build on other nips. I see it as good thing, but it does make it harder to start from scratch.