I haven't seen the talk, but based on the description and their slides, I'm pretty sure that you're conflating two separate attacks.
... credit card thieves can rewrite the magnetic stripe code to make it appear like a chipless card again.
The magnetic track data on a credit card contains (among other information) a three-digit service code. A service code that begins with a 2 or a 6 indicates that this is a chip card, which is how the terminal knows to tell you to insert the chip if you have one. By changing that first digit to a 1 or a 5 (and appropriately altering the check digit), they can trick the terminal into thinking it's a chipless card and permitting the swipe.
This attack won't work under normal circumstances, because the entire swipe data is sent to the bank to verify. Changing the service code will cause the data the bank gets to be wrong, and it'll reject the transaction "on the back end", as the article you linked to says:
"If the data on the magnetic stripe is altered it might fool the terminal," said U.S. Payments Forum director Randy Vanderhoof. But on the back end, the system would "reject the transaction."
However, merchants have the capability to do "store and forward", aka "offline mode". Slide 24 points out that EMV fails to "Prevent using modified Track 2 in offline mode", which is very true. This happens when the POS is unable to actually connect to the card networks to get an authentication from the bank. Rather than reject all transactions (lost business!) or require calling the bank to get a verbal auth code (lost time! customer confusion!), the business just decides to store all the transactions and forward them later, when things are back online. Since there's no connectivity, there's no way to know whether the data is valid, if the card is over its limit, or any of the other usual safety checks. The merchant accepts the risk of that in order to continue doing business.
Obviously, in this mode the altered track data won't be caught until it's too late, and the transaction fails to forward, bypassing EMV altogether.
... because of the way many retailers are upgrading their payment machines: They're not encrypting the transaction.
This is a separate issue, where the merchant's terminal transmits the card data to the POS in plaintext. Even if the POS then immediately encrypts it (either for store-and-forward storage or to actively transmit), it was still in the clear over one leg of the network, which provides opportunity for compromise. The section of the slides that starts on page 13 address one (of many) attacks on this: Networks shims. If you can put your device or code between the terminal (POI) and the payment app that encrypts it, or between the (non-encrypting) app and the POS software, then you can read off the data as it goes by, undetectably.
The counter to this one is on page 41 and higher: Point-to-point encryption (P2PE). With P2PE, the device encrypts the data itself, using a pre-loaded key. Now, no matter where you interject yourself into the process, you can't retrieve the card data, because it's encrypted all the way to the gateway/processor/card network.
This still doesn't protect you against skimmers (page 39) or attacks on the device's software (page 40 and earlier), but it reduces the attack surface.
