It's really the combination two problems. 1) The particular OS is configured to prefer 6to4 connectivity to native IPv4, 2) 6to4 isn't supported well on many ISPs for various reasons, and there can also be LAN issues which make 6to4 not work well, or at all. So you could say #2 here is a problem with 6to4 implementation.
Most OSes by default (Windows, and most distros of Linuxes, and BSDs) are configured to prefer using a native IPv4 address before an IPv6 6to4 or Teredo (another automatic tunneling method) address (see RFC 3484) for connections. Apparently OS X isn't. So, when a site has both an IPv4 and an IPv6 address, OS X will prefer the IPv6 address even if the system's IPv6 connectivity is via 6to4. Since 6to4 is often slow, slow to start, or just plain doesn't work on a particular LAN/ISP depending on a plethora of reasons, you'll get timeouts and such. This is one of the reasons why services like Google have a separate domain name for IPv6 based services (ipv6.google.com), instead of just putting up both A and AAAA DNS records.
If using a 6to4 connection, YMMV depending on your LAN configuration, your ISP, routes it receives, proximity to a 6to4 relay, whether the 6to4 anycast address (184.108.40.206) your ISP sees routes to a reasonable place, etc. This is why it's so problematic. There are a lot of variables which can make it either not work at all, or affect its performance. Plus, being a tunneling scheme, performance is already degraded vs. a "native" protocol even if it worked perfectly.
6to4 works by constructing an IPv6 address in a special range reserved for it (2002::/16) which encodes your IPv4 address into the IPv6 address (i.e. if your IPv4 is 192.0.2.10, the 6to4 IPv6 prefix will be 2002:c000:20a::/48, out of which you can subnet and make /64s, etc). The traffic is then sent over a IPv4 6in4 (IPv4 protocol 41) tunnel to the "nearest" 6to4 relay which is reached via the 6to4 anycast address (unless the relay server is configured manually). Unfortunately, many ISPs have this anycast routed to a far away relay. For instance, two friends' separate cable ISPs I tested this on had the traffic routing from eastern Canada and the western USA to a relay server in Sweden!
Traffic from the IPv6 internet to the 6to4 space is routed from its source to the "closest" relay server advertising the 6to4 space in BGP. The relay extracts the IPv4 address from the 6to4 IPv6, and the IPv6 packet is encapsulated in a IPv4 6in4 tunnel packet and sent to the extracted IPv4, which should be the user's 6to4 router. This trip from the origin to the 6to4 relay can also often be a long distance, depending on the origin of the traffic, and then of course the tunnel packets have to make their way over the IPv4 internet to your 6to4 router. Obviously this can make for some pretty serious asymmetric routing which can cause its own problems.
Other problems such as 6in4 being blocked anywhere along the forward or reverse path to the user's 6to4 router will cause it to fail. Also, if the implementation isn't smart enough to know that a particular box is behind a NAT, and constructs a 6to4 IPv6 address based on the NATed address instead of the public IPv4, it will obviously fail, since the return traffic will be sent to a private IPv4 address by the relay server instead of the user's public. I don't know if OS X does this or not. And finally, most firewall/nat boxes with a single public IP shared by many computers can only support a single 6in4 (and therefor 6to4) tunnel behind them, since unless they inspect and track the tunneled IPv6 packets (plus some other implementation enhancements), there's no way it can know which inside host to send return traffic to when it deNATs them.
Note, that none of this is a basic failing of IPv6! The problems here are with implementation details of a well intentioned automatic tunneling method designed to provide IPv6 access to IPv4 only users in a "automatic" manner which doesn't require much user knowledge or intervention. Unfortunately, it didn't "work as intended" based on some of the factors I mentioned above, plus probably others I haven't thought of. :-)
This should explain the problem as well as I understand it. Hope it wasn't too boring. :p