I would say that is bad to have many instances of publishers or subscriptions on the same topic in the same node, if you can avoid it and you don’t mind them sharing queues.
In ROS 1, at least publishers, and I think subscribers, for topics were singletons. I know that if you created a publisher on topic foo in one place, and in another part of the code you created a publisher on the same topic foo then you’d get a handle to the same publisher. This is bad, for example, when you wanted to specify a different queue size for each, see:
But is was good, on the other hand, for avoiding duplication of resources when you didn’t mean to do so.
If it the same is true for subscribers in ROS 1 (I didn’t check yet), then it could also be bad that they would share the same queue. Consider a subscriber with a queue size of 10 and the user creates two subscribers, each with a different callback but on the same topic. When a new message is received on the topic, does the message get delivered to both callbacks or just one? If it is delivered to both, what happens when one callback is really slow, does it keep the messages in the queue until all callbacks are done with each message?
In ROS 2 we wanted to make sure that each instance of a publisher or a subscription had the option to have their own queue. That makes the semantics clearer and it makes it possible to write code that cannot be interfered with from other code in the same process (which can be a concern when using the ROS API’s from within a library or when making nodelets). The trade-off is that each time a user creates a publisher in ROS 2, there will a queue and any other associated overhead generated as well.
That all being said, I think that we make users aware of this, then making a singleton for your publishers and subscriptions is something the user can do on their own.
I don’t think you need to worry about it too much. I’m not 100% certain about the overhead on the network, but you could expect some overhead in memory/cpu usage and possibly some overhead on network due to introspection and discovery processes. However, it would always be better to only create new publisher and subscription instances when you explicitly need a unique one with it’s own settings and resources.