It is a big fat "it depends". If you don't need the extra data width then in theory 32-bit code could be faster as smaller units are being loaded from cache or main memory. But depending on your architecture there could be alignment related performance issues that 32-bit instructions will run into but 64-bit ones will not because the memory fetch portions of the processor and related subsystems are optimised for 64-bit alignment.

A 32-bit application is going to be older too and won't be using non-64-bit-specific enhancements present in the processor families that may help it more than being able to deal with bigger integers. More registers being available for instance, additional SIMD instructions (for doing more with collections of smaller values) or wider versions of existing SIMD instructions.

There may be other architecture dependant factors to consider too.

Other considerations come from running 32-bit apps on systems that support both 64 and 32: you end up with two versions of some libraries in RAM which could give a one-off hit upon loading an app but also means more memory pressure so other stuff could be being pushed out and will need to be reloaded later from slower storage later when next called. That won't matter for libraries that one one app is using anyway, but for shared system libraries it could be significant. Also if the 32-bit libraries are really just a translation layer calling the 64-bit ones, then there is extra work per call that isn't related to how many bits you can process in one instruction. The extra memory pressure may slow down other apps when you switch back to them (via user action or due to them having a background service portion that needs to respond to an event) as more pages need to be reloaded from slower storage instead of already being in RAM, meaning the slow down the warning is talking about may not be immediate or affect the current app at all.

"64-bit gets faster performance because you can do twice as much in one step" is a useful explanation for the general public, one that is true (or at least not completely false), easy to understand, and much simpler than the larger collection of real details. A bit like in GCSE physics when you are told "yeah, what we said in science lessons before is a simplification and on some levels actually wrong, this is what really happens" and in A-Level physics you are told "yeah, what we said at GCSE level is a simplification and on some levels actually wrong, this is what really happens" and so on up your education as far as you take it. The simplification is needed to get the message across to those who don't need or care to know more, but doesn't hold as much water upon more detailed inspection.

I think talking about the performance hit is a mistaken way of talking to the users about the matter though because for a great many cases on an iPhone that is unlikely to be significant as the reporter here notes. And even if there is an effect overall the common user will not notice an immediate effect and assume going forward that there is no effect at all and that the warning was being over sensitive. A better way to get the message over on an iDevice is to point out that more battery power will be consumed. This is equally true (if not more so) and people are likely to care more IME.