According to conversation on https://github.com/letsencrypt/boulder/issues/593 they couldn't support it because one of their datacenters didn't support IPv6 traffic.
There were some other factors on our side that contributed to the delay as well. It comes down to the fact that our priority has to be reliable and secure operation of the services we're already offering.
I'm glad it's finally here though, and now Let's Encrypt won't be a blocker for someone else's IPv6 deployment!
What's up with that anyway?
System Admins routines make mistakes with complicated host names and trying to acquire an accurate inventory is an absolute nightmare. This ties into IPv6 because why would anyone take that disfunctional system, which barely works with 'easy' IPv4 addresses, and make it even more complex? We would have to support both IPv4 and IPv6 simultaneously and firewall rules would get much more complex initially and they are already a huge issue for me to get changes made.
At my old job this was similar. Even though it was in the financial industry and that particular company was rolling in profits it couldn't keep enough network engineers around to save it's life. The turnover was high, documentation was horrible and projects to make things better languished on in the ether.
No no no, forget the whole IPv6 thing, just run IPv4 for all things internal and gratuitously support IPv6 outside if you really have to. I jest of course, but that is the reality of my corporate life in the last 6 years in two fortune 500 companies.
That said, I think there's often a strong argument for only using IPv6 for the internal parts of a network. IPv6 actually simplifies things, and where IPv4 remains needed, it can be encapsulated and routed over a v6 network.
But it takes a team which understands the v6 world and is able to take advantage of the benefits for this to become a reality.