For what it's worth, there's been a bunch of work around backlogs (to simplify bouncers, though if more niche IRCds wanted to incorporate it natively that'd work too). CTCP isn't great, but the simplified CTCP I-D improves things for clients. DCC I'm documenting, hoping we can replace it with something more appropriate and/or extend DCC as it currently exists in a backwards-compatible way (there's a loooot of debate and discussion on DCC in the v3 WG. once we fix up a bunch of misc protocol stuff it's definitely something we'll approach).

For sure, simplicity is better than complexity. A fair amount of the v3 work aims to simplify things that are already done in a bunch of vendor-specific ways and bring them all under one clean, well-specified roof. Always happy for extra help there :)

AFAIU the site is just documenting existing practices, so I don't think they are over-complicating anything - things just were already complicated (and poorly documented).

Yep, pretty much. Unfortunately the protocol's gotten fairly complex without standardisation to keep everyone on the same track. I do my best to simplify the text where I can, but a little more in-depth and correct is better than something simpler that doesn't match real-world implementations.

edit: With regards to encryption and backlog, they're being worked on in the IRCv3 WG, worth checking out if you're interested in changing the protocol for the better: http://ircv3.net

You are right. My comment was more towards the ircv3 wg.