I'm aware, but I was talking more in the practical sense.
The attacker can replace the iframe with his own and proxy it, or perhaps simply display an error and ask the user to re-insert his payment info into the actual stripe form.
The attacker can replace the server's response with his own form that pretends to be Stripe's, too. In the end, there's no real defense against phishing.
Flow 1: User visits shop.com, selects some items, hits checkout, enters his credit card details into a form on shop.com, hits submit, gets emailed a receipt.
Flow 2: User visits shop.com, selects some items, hits checkout, is redirected to a form on processor.com, enters his card details, hits submit, gets email a receipt.
Now flow 1 and flow 2 could be the same internally if the form in flow 1 was actually from processor.com, just embedded into an iframe displayed on shop.com. But the key is that the user has no idea if it is or not.
The form in frame 1 could be in an iframe from anywhere, or it might actually be embedded directly into the page and posting, again, to anywhere. You just have to take it on faith that shop.com hasn't been compromised, and isn't now sending your details to malware.com.
In flow 2, you only enter your details into a form on processor.com; you no longer need to worry if shop.com has been compromised, you just need to verify that you're actually at processor.com, and not proccesor.com or whatever.
A form that has been replaced is quickly picked up on as the merchant stops receiving payments and the customer will call up to complain that they haven't received the product. An iframe around Stripe's can send the PAN off to a malicious server and then continue the payment process.
The attacker can replace the iframe with his own and proxy it, or perhaps simply display an error and ask the user to re-insert his payment info into the actual stripe form.