Message dispatch: If you really, genuinely, need higher performance, you can grab the IMP yourself. On some architectures, jumping through an IMP is actually faster than an apparently direct call (e.g. because of the way the dynamic linker works).
Object layout: Again, if you care, you can grab a pointer to the variable you're using.
GC: I doubt the GC is used all that much in practice because retain/release is faster and better understood. Your claim that reference counting is "the slowest high-overhead form of GC" is wrong, because it is based on old automated implementations that inserted reference counting operations automatically everywhere. Manual reference counting is not usually dealt with in the GC literature, and as it happens Apple's more recent automatic implementation, ARC, does substantially better than the historic auto-reference-counting implementations that most papers discuss (indeed, in some cases it is more efficient than manual reference counting).
Another thing worth noting is that Apple's Foundation (and Core Foundation underneath it) have very efficient implementations of the collection data types, and indeed adapt their behaviour depending on their content. This does not happen to the same extent in STL or Java, and means that simple programs can sometimes outperform their equivalents in other languages merely because high performance implementations in competitor languages would require that the author tailor his/her use of collections according to e.g. the number of items presented, which is not necessary with ObjC (at least on OS X). You can read a little about this kind of thing here:
http://ridiculousfish.com/blog/posts/array.html
Finally, I'll note that in ObjC, you always have the option of writing performance-critical code paths in plain C, or even in assembly language. You can even construct your own task-specific JIT, if you like (which is made considerably easier by the availability of the LLVM libraries, though they are not the only possibility).
To summarise: I don't buy your "Hotspot JVM means Java is faster" argument. It's based around a set of assumptions that don't hold in practice. Java is definitely a fast language these days, and for some applications the JIT does indeed result in a performance boost, but it is always possible to equal or exceed Java's performance in plain C (and hence in Objective-C), albeit with some degree of effort.
Object layout: Again, if you care, you can grab a pointer to the variable you're using.
GC: I doubt the GC is used all that much in practice because retain/release is faster and better understood. Your claim that reference counting is "the slowest high-overhead form of GC" is wrong, because it is based on old automated implementations that inserted reference counting operations automatically everywhere. Manual reference counting is not usually dealt with in the GC literature, and as it happens Apple's more recent automatic implementation, ARC, does substantially better than the historic auto-reference-counting implementations that most papers discuss (indeed, in some cases it is more efficient than manual reference counting).
Another thing worth noting is that Apple's Foundation (and Core Foundation underneath it) have very efficient implementations of the collection data types, and indeed adapt their behaviour depending on their content. This does not happen to the same extent in STL or Java, and means that simple programs can sometimes outperform their equivalents in other languages merely because high performance implementations in competitor languages would require that the author tailor his/her use of collections according to e.g. the number of items presented, which is not necessary with ObjC (at least on OS X). You can read a little about this kind of thing here:
Finally, I'll note that in ObjC, you always have the option of writing performance-critical code paths in plain C, or even in assembly language. You can even construct your own task-specific JIT, if you like (which is made considerably easier by the availability of the LLVM libraries, though they are not the only possibility).To summarise: I don't buy your "Hotspot JVM means Java is faster" argument. It's based around a set of assumptions that don't hold in practice. Java is definitely a fast language these days, and for some applications the JIT does indeed result in a performance boost, but it is always possible to equal or exceed Java's performance in plain C (and hence in Objective-C), albeit with some degree of effort.