Strategies for managing M libraries deployed by N applications... (and default limits on project subscriptions)

I have teams writting M libraries to be deployed in N applications (all in separate repos). I would like the applications to be able to subscribe to changes in the library. It looks like the best way to do this would be through Pipeline subscriptions. Is that correct? Should I just rely on the N applications subscribing to the projects they need, or would it be worthwhile to have a single “orchestrator” project that the M libraries trigger and the N applications subscribe to?

Also, I noticed the docs say that the default limit on subscriptions 2 and that admins can adjust it. I would anticipate us having about into to the 100-200 subscriptions at most. Probably ~50 more realistically. Is there a reason it’s set so low? Any performance issues to be aware of?