There's no generic case here. Depends on pretty much everything. Definitely more than 1, unless it's a page for displaying a single number. Definitely fewer than a billion. :)

I mean, should one expect performance problems with half a million subscriptions?

What is a "problem" in this context? What do those subs do? How often do they get re-evaluated? What does their re-evaluation trigger? Just deref'ing a mil of already evaluated reactions preceded by a mil of subscription cache lookups will take some some 100s of ms. But if will be nothing compared to the rest of the app where you're using a comparable amount of components.

If there's no reason to split a subscription into 2 or more - don't split it. If there is a reason to do it - do it. If you have performance issues on target platforms - profile and handle those issues instead of dealing with hypotheticals with no context.

As a general guideline, keep your number of first-level subscriptions (the ones that depend on app-db) to a minimum.

My experience is that around 10's of thousands you have to start thinking about it more carefully. As mentioned, once you get to 10's of thousands of subscriptions, you're also going to start running up against secondary performance costs, like rendering all that data in the browser. As a baseline rule of thumb, my point of comparison on whether I should use a subscription/reaction versus a naive un-cached computation is whether the cost of the computation is meaningfully more than an equality check on the result. It's easy to underestimate the overhead and cost of subscription/reaction equality checks.