The things that can be "faster" are typically not the bottlenecks in Objective-C programs, as the fine article rightly mentions in passing.
On the other hand, a lot of the really slow parts of recent Objective-C "enhancements" are now mandatory in Swift, for example the Automatic Reference Counting (ARC) support, which is actually a big part of the 100x and more slowdowns.
Another issue is that you have copying semantics by default. The claim is that this can make things faster, but for common objects like arrays and dictionaries it first makes things a lot slower (once they fix the completely borked array semantics).
In all of these cases, you have very slow defaults that you must trust the compiler to make fast again. The claim is that the semantics make it easier for the compiler to optimize. This is true, but so far practical experience appears to be that these two don't balance, that is the compilers don't get enough extra information for optimization to compensate for the loss in performance you get from the semantics being expensive by default.
Except in well-chosen benchmarks.
In fact, even in FP languages that have much tighter semantics and therefore much better opportunities for the "sufficiently smart" compiler to do its magic, you tend to see people dropping down to nasty imperative code (effectively C in all but name) to get decent performance.
Swift's semantics are less tight, so I think it's going to depend even more on the programmer writing fast, imperative code, "C in all but name". Again, there are a few things that help the compiler here, but again I doubt they will generally be able to compensate.
I think the biggest issue with Swift performance is that it is focused on helping the compiler, rather than the programmer. The performance model is, at least so far, highly non-linear and non-intuitive. This will hopefully get better, but the semantics I've touched on make it difficult, they are inherently highly non-linear and inherently difficult to predict.