There are many issues that prevent us from easily serving your use-case, unfortunately. I'm not completely sure about the details around this specific case, but historically we've had to restrict connections from similar software that makes N:N connections (or even N:M connections) to our network due to our connection limit rules quickly becoming unmanageable. We've recently implemented new software that should make this a little bit easier for us (and we've accordingly started being a bit more lax about it), but this is a fairly recent development.
Additionally, we hesitate to cater to this use-case as it often ends up turning into "we want your network to relay messages between our bots" instead of "we want to talk to other people". We've found that channels used for such bots are typically not sufficiently staffed and frequently a target of abuse, which ends up taking network staff time to resolve.
Lastly, we've had a number of technical issues supporting certain pieces of IRC client software. Older versions of EiraIRC in particular have some nasty bugs; the worst of which is that they tend to get stuck in some state where they hold multiple connections to the network open while continuing to attempt to connect again and again, with no delay. While this doesn't impose load that our servers can't handle, it does generate a lot of administrative log traffic that is bogus and dilutes important log traffic.
Many of these use cases can be covered by IRC, but our network isn't configured to handle such use easily as it often looks very similar to the sort of abuse we usually deal with. The common denominator in most cases like this is that it's taking too much of the staff's time and attention to support the channel and its clients. Our time is finite, and for the health of our network, we'd rather say "no" to a few channels than to make all channels suffer from thinner network staff resources.