Tunnels promote poor paths
"promote"? Tunnel topology does not (necessarily) match the underlying
topology, especially if you choose (or are forced to accept) a distant
broker. But "promote"?
, they bring along LOTS of issues wrt PMTUD,
PMTUD that doesn't work on v6 probably doesn't work on v4. I agree that
a bad PMTU can wreak more havoc on v6 than v4, but most of the issues
are workaroundable.
asymmetry of paths, improper/inefficient paths (see example paths from
several ripe preso's by jereon/others), longer latency.
All relating to the above. I suspect you really mean paths in the
underlying topology, which is a "by definition" issue. None of these are
necessary features of tunnels.
Given the relatively low number of tunnel terminating services, and the
fairly low level of choice available to people who want tunnels, these
are bigger problems than they need to be. More demand will see these
problems (as with so many transitional issues) lessen substantially.
If the tunnel
exits your border you can't control what happens and you can't affect
that tunnels performance characteristics.
Whereas with IPv4 you have complete control over everything that happens
once packets exit your border? This is no different with IPv6 than with
IPv4, except that you have fewer choices at present, so must make more
drastic compromises.
it's 2010, get native v6.
Easily said 
If you can't get native IPv6, then using a tunnel lets you get started;
it lets you begin educating, testing and even delivering IPv6-based
services. If, on the other hand, you wait until everything is perfect,
you will be waaaay behind the eight-ball.
Oh - and tunnels are usually way cheaper than native connectivity, so
it's easier to get the idea of going v6 past the bean-counters.
So: Yep, native IPv6 if you can get it. Otherwise, take tunnels. But
whichever you do, do it now.
Regards, K.