I'd say for most organizations, the public-facing corporate website breaking is less of a big deal than if all e-mail routing ground to a halt for a day. Not that this was likely to happen today.
HTTP is also an easier IP application to troubleshoot than say SMTP, DNS, or even and routing at layer 3. When troubleshooting effectively, you make small changes then observe the effects of the change. Which is really the next reason not to test SMTP on IPv6 today...
Participants aren't just testing HTTP servers today. Someone also had to keep a close eye on DNS infrastructure, and network layer 3. I have seen Cyrus IMAP Murder clusters failing to replicate with link-local IPv6 turned on in DNS and on the IMAP servers, while IPv6 was disabled at network layer 3. That tends to back up mail routing real quick, when something like IMAP services do not function as expected. Its nearly impossible to troubleshoot a situation like that, mail routing is backed up, DNS queries all seem to work, and then you have Cyrus spewing weird incomprehensible error messages which might lead you on a red herring troubleshooting hunt. I am sure most participants do not want a shit-storm to deal with today, just by throwing mail services into the ring.
So our own organization turned on IPv6 at layer 3 on a few isolated VLANs a couple months ago to test everything out-of-band in a lab environment. We learned a few lessons like what exactly NDP (Network Discovery Protocol) does in IPv6, and how to firewall an IPv6 Linux server. The ICMPv6 rules are drastically different than the equivalent on IPv4, because you're supplanting ARP with NDP for the most part. Gradually we turned on IPv6 in the production DMZ VLAN. Then turned IPv6 on for one external DNS server and the corporate website, observed the effects for a day and made adjustments. Then finally turned IPv6 on for the remaining external DNS servers. At which time, it was discovered our TLD doesn't fully support IPv6 DNS glue yet, despite them being a fairly early adopter of technologies like IPv6 and DNSSEC.
Today was about testing the waters by sticking a toe in, not diving in head first to a pool with only 3 inches of water. Events like today's puts pressure on hardware vendors, major ISPs, and application vendors. It would be great to be able to dump some network stats for my IPv6 interfaces on the DNS boxes, although our network monitoring systems don't quite fully support IPv6 yet. There really isn't a good way to differentiate DNS or interface stats between IPv4 and IPv6, yet.
I kept some pretty thorough notes on IPv6 Linux configuration for anyone who hasn't had a chance to play with IPv6, yet, link here.