Ok, so first let me say that I'm not making the case that obfuscation doesn't incur a performancy penalty in many cases. But there are many techniques that aren't such a performance drain as you'd think and instead impose more of a size penalty --something we might be able to live with a little bit more. One of my favorites is when you duplicate a code block several times, introduce small bugs in each of the blocks, and then make it difficult to determine which of the blocks is actually executed. Sandmark does things along these lines.
BTW, the examples in the article for HelloWorld are illustrational and intended to communicate the concept, and weren't intended to be taken as being state-of-the-art. Sandmark, on the other hand, does some pretty clever stuff.
If you tailor your obfuscation approach and actually think about what it's doing (as opposed to blindly picking a technique), you can keep the performance penalty fairly minimal many times. In the case of Java or even ObjC, name obfuscation (as you mentioned) can go a long way and it's trivial to do with a few perl scripts.
I don't know that I'd agree that 90% of the time your sensitive code areas are going to have to run fast. Maybe so, but maybe not. I wouln't feel comfortable saying that it's anywhere 90% of the time though. Certainly, protecting against nag screen removal, registration code patching and basic security mechanisms along those lines don't need to run at lightning fast speeds, and are some of the most common ones that come to mind -- I'd think that this is especially true for "small" independent developers, who often have created more of a software engineering masterpiece than some cutting edge new algorithm for something.