Hmm. Could be worth asking some IPv6 experts to help think about this. The best IPv6 person I know in your area (assuming you’re in the Bay Area) is Cisco’s Stig Venaas - if you want somebody that is happy to sit down with a beer and discuss what’s best he’s your guy. For myself, with only a little expertise, it seems as though for 6to4 specifically it makes sense for Let’s Encrypt to perform the encapsulation gateway function itself (I mean not necessarily in Boulder, but on hardware under your control) so that you only have the same worries about hostile middle boxes as for an IPv4 applicant.
A 6to4 gateway gets to interpose itself between Let’s Encrypt (or at least one Let’s Encrypt site) and all 6to4 applicants. That’s acceptable if it’s your gateway, or if it’s operated by a trusted supplier that you’re contracting with, but it doesn’t seem acceptable if it’s a third party and especially if that third party isn’t under contract to you for the service. Thus I think Let’s Encrypt should ensure a specific node is configured as the 6to4 gateway, not the default anycast address, and that this specific node is operated by them or by a trusted supplier.
If that’s not practical for some reason it may be safer to forbid 6to4 (but not ordinary IPv6) which anyway makes up a very small percentage of all reachable IPv6 Internet hosts.