It does vary on many factors and specifics of your app and data. I tend to settle down in a mixture of both approaches in the same application, plus app cacheing subscriptions where appropriate:
Low-update type subscriptions that are required throughout many parts/pages of an application (e.g., reference tables) are ideal for global/higher-level templates so they are subscribed once and remain resident on the client for the whole session. These also tend to be the type of subscriptions that are reused across many clients (same query criteria) which tends to be good from the server perspective.
Other subscriptions make more sense at the lower-level templates where they are used. Thing like data needed for CRUD style processing where you need all the data for a specific document, in selected screens that are not often used for the same document in the same session, so you can display/update details.
Somewhere in between, I found that some package like ccorcos:subs-cache can be very useful, saving the unsubs/subs for same document that sometimes happens when the user tends to go in/out/in of screens that need the same subscription in a short time frame (e.g., change some document in a screen/page, then go out to another route to check the effect, then comeback again to update to try something else…).
To check the effect on the server of different approaches, percolate:server-info is a package that I found quite useful.