If you don’t actually need the reactivity, then it will certainly cause less overhead if you do turn it off. On the server that also helps in lowering memory usage and performance overhead.
I don’t have benchmarks for you, and I’m not sure how many people have already had to optimize performance at this level.
Most of the time the additional effort (i.e. resulting decreased ease of use) of moving from pub/sub to Meteor methods shouldn’t be worth thinking about this too much.
But I do understand the desire to always stay in keeping with what’s the most performant application of an API, if there are no other more important priorities to consider (such as ease of development; fewer lines of code to maintain etc).
If you have a specific case (cases) that you’re looking to optimize you could share some details about those. Optimization is usually something that should be done in a very deliberate and targeted effort. Otherwise sticking with the most standard and “good enough” patterns is often the best thing to do.
Effectively most of the answer is already implicitly stated, i.e. for me it’s ease of development & maintenance that take precedence over performance concerns where there are no large, unacceptable performance overheads generated.
One thing that I do always think about, at least regularly and in conjunction with publishing new releases, is server performance overhead and memory usage resulting from the “merge box” algorithm that’s tracking which clients are interested in which collections/data and what’s already on which client. That one could definitely get out of hand very quickly, if pub/sub is not used wisely and more than a handful of users hit the app at the same time.
So intending to not overpublish/oversubscribe is a really good idea and something to always consider once the app moves towards production use and the amounts of data and numbers of (concurrent) users get larger.