You had me up to the point beyond the assertion that the "experimental flaws" which invalidated the performance claims of Microsoft were grounded in the failure to replicate the Oracle optimized implementation in the Wintel envirnoment. This seems a valid claim (Although, as you seem to imply, by no means does it bias the results in .Net's favor over J2EE. "The differences might be real, but we just can't tell." Performance differences may well be exacerbated in the Wintel incarnation of Oracle/J2EE).
Your further claims are more problematic. You make much of the fact that the implementations support different sets of "nonfunctional" requirements, especially the J2EE emphasis of portability over performance. By spinning the question this way, you have set up criteria that effectively does away with the significance of performance measurements entirely. As you say "if approach X satisfies my higher-priority criteria, will it be fast enough?"
Apparently your higher-priority criteria is mostly subsumed in the ideal of portability, not the "best practices, design patterns, and architectural ideas" that were the stated goal of the Pet Store Exemplar.
Framed in this way .Net is the loser always because of its very nature, not because of any particular or general implementation. Why talk specifics at all? .Net is a creation of Microsoft and therefore ineluctably tainted by association with a single OS? What about the ECMA adoption of C# and the .Net framework? Do other ISVs have to build their own CLR implementations in order for .Net to be perceived as open and portable?
You imply that J2EE is inherently superior because it's implementation is not database nor OS specific. And that .Net is somehow corrupted because its implementation is specific to SQL server on Intel.
Unfortunately platform portablity is more often a specification overkill, as you rightly point out. All the performance optimizations you suggest (in your "springboard" project and in the links in the reference Sun pages, all depend on eliminating the generic implementation of the Data Access Objects, and therefore, of the portablility of the application.
Just as the performance of the J2EE implementation can be modified at the expense of portablity, the .Net implementation can be made more portable at the expense of performance. Doubtless Data Objects can be forged in .Net that are at least as abstract as those in J2EE. Stored procedures can be done away with, similar results can be forged in a more generic implementation of SQL (although the use of store procedures may be an interesting question with regard to design patterns and best practices, which goes unexamined). With objects/components, much is possible.
Your real theme here is the inverse relationship between portability and performance, a relationship that is independent of the existence or "inherent" superiority of J2EE or .Net.
I think you make an unclear distiction between the fact that Oracle addressed "performance bugs" that is, somehow, not the same thing as "tuning" the application.