The cost of communications grows in a quadratic fashion in several directions as the number of replication nodes in a cluster increases. Note the following relationships:
It is necessary to have sl_listen entries allowing connection from each node to every other node. Most will normally not need to be used terribly heavily, but it still means that there needs to be n(n-1) paths.
Each SYNC applied needs to be reported back to all of the other nodes participating in the set so that the nodes all know that it is safe to purge sl_log_1 and sl_log_2 data, as any "forwarding" node could potentially take over as "master" at any time. One might expect SYNC messages to need to travel through n/2 nodes to get propagated to their destinations; this means that each SYNC is expected to get transmitted n(n/2) times. Again, this points to a quadratic growth in communications costs as the number of nodes increases.
Mind you, the work will be divided across n nodes, so while the total amount of work goes up, the amount of work per node increases in a merely linear fashion.
This needs to be tempered further, as people have had the habit of pointing at this portion of the documentation and crying "quadratic increases in replication costs!!!" (When it wouldn't be surprising if, quite frequently, those that are crying out this way mightn't necessarily know what O(n^2) truly implies...)
This is a set of overhead which is added to the work actually done on replication. If there is very little in the way of INSERT/UPDATE/DELETE work to replicate, then this overhead will quickly become dominant, but, by the same token, there's very little real replication work to be done, in which case this presents little problem. On the other hand, if there is a lot of replication work to be done, the SYNC events will tend to grow, whereas the "confirmation bookkeeping" doesn't increase in quantity, and should be able to be buried in the noise of the "real work."
This points to it being a bad idea to have the large communications network resulting from the number of nodes being large. Up to a half dozen nodes is known to behave reasonably; every time the number of nodes doubles, this can be expected to quadruple communications overheads. Of course, the expected benefit from having more nodes is likely to fall each time you add an additional subscriber, so the value of adding huge numbers of nodes is likely to be pretty low.
Adding the first subscriber provides a failover target, which is likely to be mighty valuable.
Once you have 5 potential failover targets, the risk of losing all of them should be low. And the added complexity of having an extra node which needs to be configured, installed, and monitored is eventually likely to outweigh the value of having that failover target, when multiplied by the very small likelihood of this being The Target in case of failover.