Some languages such as Java have “static methods” that live in a class's namespace, but do not use dynamic dispatch. Instead, they are dispatched statically at compile time (hence their name). Dynamic dispatch is less efficient than static dispatch, since we have to search for the method in all classes of the object we're calling a method on. A central point of OOP is that we do not know the class of the object we'll be calling methods on a priori.
In Java, the properties of static methods make them a good candidate in two use cases:
“Class methods” (which Java doesn't have), e.g. some constructor with a better interface. These are problematic in Java since static methods can't be inherited, and classes can't be passed around as objects. The result is often an extra Factory object.
Objective-C can use real class methods in these cases, which is welcome flexibility. After all, Objective-C has a metaobject protocol, and classes are objects.
Low-cost method calls. Since calling a statically dispatched method is much cheaper than invoking a dynamically dispatched method on an object, static methods can be used to optimize code.
Since Objective-C builds upon the C language, we can always use plain old C functions. C does not have dynamic dispatch, and function calls are very efficient. However, C has no concepts of classes and namespaces, so great care has to be taken to avoid name clashes.
The object-oriented paradigm turns out to be very good at encapsulating complexity. While this makes it easier to design systems, it also makes it more difficult to reason about performance.
The point of the post you mentioned seems to be that using the C subset of Objective-C (i.e. the procedural features) can be a very good idea, since it contains a couple of sensible features the object-oriented parts of Objective-C won't give you. The sentence “Static functions are nicer than shoe-horned class methods” is likely to mean that if you have some function that does not have to be an instance method, using a C function is probably a good – and certainly more performant – solution than putting it into a class method (which would also miss the point of classes-as-objects).