Don't make the mistake of assuming that I think Adobe should do a 64-bit Linux port of flash. I don't. I don't use flash nor do I care what they do. I was responding specifically to your argument that x86_64 is not worthwhile.
You're still arguing from a non-realistic position: It's not reasonable for distributions to do profile driven compilation because of the load it imposes on the build infrastructure. Likewise they can't reasonably do whole program optimization because of the enormous memory requirements. Today in the real world x86_64 does give real measurable performance improvements. The floating point improvement alone justifies it.
Likewise, being unable to support non-P4+ systems isn't reasonable. There are still plenty of x86 CPUs sold today without full SSE2 support (Geode, for example). It makes a lot of sense to batch together all of the little non-backwards-compatible micro-architecture improvements and break compatibility once, offering x86_64 for new systems, and i486 compatible code for everything else. Which is exactly what is being done.
It seems to me that you have missed the point I was making about 3%. People are paying $240/cpu for what is *at best* a 6% improvement. If you have any floating point workloads x86_64 is a big win, and even if you have purely integer workloads x86_64 is still a worthwhile improvement in typical cases.
Your cited benchmark here is antiquated: Would you really expect GCC from 2004 to take full advantage of a CPU architecture which had just become available in 2003? I do not have a copy of the speccpu benchmarks, but I'm familiar with the mincost optimization code (mcf) that performed so poorly on x86_64 in your cited benchmark. My own quick test here shows mcf on x86_64 performing only 3% slower than when compiled for x86 with gcc 4.3.0 on core2. My test problem[1] may not be comparable to whatever is in specint, but this suggests to me that the 40% hit documented in your linked benchmark is probably no longer representative of x86_64 performance with GCC, even on one-off micro-benchmarks.