My argument is that Swift will be primarily used to write high-level apps. For these apps, message passing is almost never a bottleneck. Swift is not going to replace the optimized C and C++ code, especially for the really low-level stuff.
But even if Apple does decide to rewrite all the Core* frameworks et. al. with Swift, there's still an argument that Swift should use message passing by default, and a way to opt in to vtable and direct dispatch for performance-critical code. For higher-level apps, message-passing is a lot less useful if it's opt-in.
As for the IRC and Latin conjugation, yes, those problems can be solved in other ways, but those other ways involve more (mostly glue) code. Trading more code for execution speed is the wrong tradeoff when performance is good enough.
You're correct I want to stick with Objective-C, but not that I have little experience with functional programming. I love functional programming. I love most of Swift. But for the specific problem domain of Mac and iOS apps, I love Objective-C. It makes working with GUIs much easier than anything else out there, and the ability to method swizzle Mac apps is great for third-party add ons.
Also, you are completely ignoring the fact that CPU cycles aren't just about time - they are about energy. Increased performance means longer battery life, or more sophisticated apps that we can use all day.
I don't see how you can be correct about the IRC example requiring more glue code. Surely at the very least you need a table matching commands to selectors. How would this be any different to a table mapping command to closures or functions in swift?