Your specific scenario has a very subtle difference that makes it a little more understandable as to why a user might be frustrated. The difference being that you're using a round-robin server which is sending you off to a random server, one that might /kill you.
Consider this: if you were directly connecting to said server that /killed you and you kept getting killed, you would not want mIRC to keep retrying... or rather, the network admins would not want the IRC client continually retrying. They also don't want to /gline you, because their /kill's might not be based on hostmasks (but rather some kind of more complex geoip lookup). This puts them in a position where they have clients flooding their networks but cannot permanently remove them. And as you said, this usually happens when you leave the computer for a few hours and come back to see you've been hammering the server every few seconds, which is the sort of flood they don't want.
In the above scenario it makes perfect sense for mIRC to halt connections after a /kill so that network admins don't have to deal with such connections. In your specific scenario, though, the round-robin server makes it so you might get a bad server, once, but the next time you probably will not, so it's okay to continually reconnect. Unfortunately, mIRC has no way of differentiating these two scenarios, and since the first one is more serious, mIRC plays it safe.
I think your example brings to light exactly why opers want this behaviour in the first place, so thanks for bringing it up.
