It's theoretically possible to deploy Let's Encrypt now for IRC servers, which removes the cost issue. The new problems become the automated creation and deployment of IRC server certificates. You'll most likely need to use the DNS-01 challenge type, since most IRC servers aren't running a HTTPd and even if they were, you couldn't guarantee that the ACME server would pick the IP of the actual requesting server out of the "pool" records (e.g. irc.example.net). Using DNS-01 means you'll need to write code to interface with your DNS server, which also means securing that interaction (so other people can't modify your DNS records and get signed certs for your domain as well).
I actually manage the (signed) certificates for one of the IRC networks I'm an administrator for. Our two blockers for deploying Let's Encrypt are the aforementioned challenges with DNS-01, and the fact that our software currently validates server-to-server links using the fingerprint of each server's individual certificate, hardcoded into the configuration file. If we're switching certs every 3 months, we'll need some way to either distribute certificate configuration more efficiently or we'll need to change the ircd to verify the certificate chain instead of the fingerprint.
FWIW, our current deployment of signed certs is the "one cert to rule them all" deployed to all servers on our network. This is definitely not ideal, but it's by far the cheapest and easiest option prior to Let's Encrypt. All other options we evaluated were simply way too expensive ($X,000+), extremely labor-intensive (e.g. manually obtaining a new cert for every single server every year/every time something changed), or both.
That's one of the recommended solutions for shared-hosting providers who don't want to use DNS-based validation.
Running a HTTPd on each server is a bad idea for us since it increases DDoS attack surface area. This would essentially have the same distribution issue that I would need to solve with a DNS-01 client as well, so either way new code is required.
The current draft for IRCv3.3 of the IRCv3 working group already has a draft for Strict Transport Security, see http://ircv3.net/specs/core/sts-3.3.html
We need the same culture shift in IRC clients that took place in browsers. Every IRC client should take certificate validation serious and do it properly. For that to happen, we need more SSL-enabled IRC servers and users that want to use it.