IRC servers form a spanning tree which makes it really easy to split an IRC network in two. I think this is the protocol's main weakness which should be addressed somehow. It's difficult without overcomplicating the protocol though.
I think that model oversimplifies it a bit, though for some implementations you're correct.
Often however IRC servers are either a hub or leaf. A hub accepts no user traffic directly and its IP address does not need to be publicly known. That makes it difficult to split the network since only the leaf addresses are known to an attacker.
As for the leaf servers, you can prioritize traffic between the leaf and hub over the traffic between the leaf and its users. You can also have them travel over different peers (most of the servers in the network I have experience with are multi-homed). Usually DoS attacks then manifest themselves as a large number of users timing out from their leaf server. Many IRC clients will attempt to connect to other known leaf servers when they cannot reconnect to the one that dropped them, meaning they get back onto a healthy leaf.
An attacker would then need to be able to saturate all (or at least most) of the leaf servers to take down the network. In my experience IRC servers run on networks that far exceed IRC's requirements and taking down all leafs at once would be a tall order for all but the largest botnets.
There have also been anycast IRC implementations which I don't have experience with, but I imagine they would mitigate most simple DoS attacks.