T134271 and the maintenance and security repercussions of the existing software stack are indeed part of it. Reliability, i.e. the fact that important functions on our sites (such as countervandalism) all rely on a single server (in a single datacenter) being up, is also another part of it. Us scheduling maintenance windows for simple kernel upgrades/reboots is unacceptable, as is scrambling to respond when that server inevitably goes down at some point. I detailed some of that on T185319, and happy to respond there if I can elaborate more (BTW, splitting the conversation between here and Phab seems odd -- I only found this thread since someone mentioned my name!).
Alsom The fact that RCStream was short-lived and IRC stayed around doesn't mean that IRC was better designed than RCStream, but rather that the service's user base isn't very responsive to upstream changes and/or that we didn't have a very good communication/deprecation plan, or executed that right. As I proposed on the task, IMHO the two ways forward is either accepting that our user base is slow moving and building something new that's wire protocol compatible, or deprecate that service and fund a project to help users migrate. Or a combination of both :)