I don't see how that can be true; loading a card into Apple Pay is done via photo or manually, neither of which entails a swipe of the card through something like a Square reader, which is what would be necessary for Apple Pay to provide "full EMV track read" data. The information available via Apple Pay is therefore necessarily a proper subset of that encoded into the magstripe, which, according to the Visa rep's statement, should require that Apple Pay transactions be billed under the same card-not-present fee scheme as in-app purchases and online transactions.
Your argument from packet format is irrelevant; "user interaction points" don't enter into it, under the rules defined and promulgated by the card associations. Those rules include a distinction between card-present and card-not-present transactions, made on the basis of whether or not the transaction data includes a full and valid magstripe read. Apple Pay transactions cannot include such a read, because, based on the methods by which a card can be enrolled in Apple Pay by its user, the information available at transaction time cannot be other than a proper subset of what a magstripe read would provide.
It's understandable that WalMart's Cook should be cross over this; his irritation stems from the perception that "the fix is in" between Apple and the card associations, such that they're breaking their own rules to give preferential treatment to Apple Pay.
On the other hand, these are their rules; the conditions under which various transaction fee schemes apply are defined entirely by the card associations (Visa and MasterCard, et al.), and if they want to extend preferential treatment in this fashion, then it's entirely within their scope to do so.
In effect, the rule for a card-present transaction has been extended with a clause "...or if it's done by Apple Pay". This is a special case of a more general rule under which effectively all card association operations occur, and whose most concise formulation is "Because we say so."