In the article http://www.cometdaily.com/2008/05/15/the-many-shades-of-bayeuxcometd-2/index.html the author describes:
Often with PubSub, developers feel the need to create a channel per user in order to deliver private messages to a client. For example, if a trading system wants to notify a user of completed trades, the temptation is to create a channel like /trades/a_user_id and each user will subscribe to their own channel. This approach works, but is not the most resource sensible way of solving this issue and requires security code to prevent unauthorized clients subscribing to other users channels.
What are the trade-offs between the service and broadcast channels to implement messages for a particular user? I understand the security aspect of the trade-off but what about resource overhead? I don't understand why there would be any more resources used with a broadcast channel than there would be for custom-routed service. If you could explain why one is better over the other for the use-case, rather than a blanket statement of being sensible or not, that could help lead me to a decision.
The article is pretty old, it refers to CometD 1 while we are now at CometD 3. You may want to check updates on the CometD website and read the CometD 3 documentation.
The concepts behind broadcast vs service channels are still valid for CometD 3.
The server allocates data structures for every channel is created, being it a broadcast or service channel.
In the example from that article, it is compared creating N broadcast channels - one for each user_id, versus creating just one service channel. The former solution is obviously using more resources on the server than the latter, and it's subject to sneak peeking (a client can guess a user_id and subscribe to that channel, thus receiving messages that are destined to other users).
For this particular case, all the application needs to do is to deliver a message to a specific client. For this use case, it is better to use a service channel because it uses less resources (the same server-side channel can be used for all users, without the risk that a user receives messages not destined to him/her) and it is more secure.