In my view it’s a typical messaging vs HTTP/WebHook issue.
You can implement that by exposing REST endpoints with a load balancer on the 3rd party applications but still the implementation and communication is tightly bound to each other. So changing anything in the communication, everything (microservice, 3rd party application etc.) must be touched because you have somehow a chain of communication: Device → microservice → 3rd party application and vice versa when asynchronously.
Sure you can scale that by using a load balancer and auto-scaling microservices but the microservice might be always a single point of failure. When not available it is really hard to recover and get the request forwarded to the 3rd party application as they occurred (No message queue, risk of race conditions etc.).
Using a messaging scaling concept is loosely coupled. You just define publisher and can add as many subscriber you want to without the need to touch a microservice. Device → Message Bus, 3rd party application → Message Bus. Messages are queued and you can avoid race conditions by processing the messages in the order they were sent. That’s the theoretical part 
Unfortunately Notifications 2.0 is not a “real” message bus (by design) so those concepts are not fully supported.
What can be done:
You can create a “shared” token for all the consumers and make sure the consumers have a different id in 10.16. Introducing Some Cumulocity IoT Notification 2.0 Enhancements
Still for each device you have to add a subscription but you just use one web socket connection for each instance on the 3rd party application as the ws-connection can handle multiple subscriptions for multiple devices/context at the same time.
In an ideal world you would just subscribe on an event of a specific type in tenant scope but this is currently not supported. Good news is: There is already a feature request Log in to your workspace | Aha! and it seems to be prioritized in future releases as this was also requests by the wm.io c8y integration team.