REST is synchronous in terms of request/reply, but that doesn't mean that higher-level actions must (or even should) be restricted to that cycle, so subprocesses like the notification should never have to block the stock update. Even if the requester needs to be informed about that, the stock updating mechanism should instead create a new Resource that tracks the notifications, and send the link to it so that the client can see how it's going.
But this wouldn't be necessary, because I agree that the stock updating shouldn't have to known about the notifications - but again, REST does not require it to!
The way to architect this using REST would be for the Notification Service to track how the stock of each product is currently. Since polling each product is inefficient, the stock manager could offer a feed that lists the latest stock updates, just like blogs do with posts.
This doesn't require a SPOF like a messaging bus, it doesn't suffer from the "service going pop" problem (since we've eliminated the dependency the inventory service had on the email system) and it's proven to work at a huge scale - the web.