Are you arguing that it wouldn't be trivial to replace the iframe form with a malicious iframe form? or to add an event handler and capture credit card numbers from the form used to submit using stripe.js?
This is why SAQ A-EP exists! What you are saying was correct for PCI DSS v2.0
There is a comparison of PCI SAQ A and EP, if all you do is link to a 3rd party site (or load an iFrame) and the CC is loaded in that PCI compliant site, you are OK in SAQ A.
Stripe.js is tricky. Stripe says their QSA has verified that the new version of Stripe.js will let their merchants qualify for SAQ A since the transport of credit card info happens through a iframe (you can see the updated Stripe.js https://js.stripe.com/v2/stripe-dss3-debug.js). I personally disagree with that, but Stripe Checkout definitely falls under SAQ A.
Per the linked doc: What types of e-commerce implementations are eligible for SAQ A-EP vs. SAQ A? SAQ A: Merchant website provides an inline frame (iFrame)to a PCI DSS compliant third-party processor facilitating the payment process.
SAQ A-EP: Merchant website loads or delivers script that runs in consumers’ browsers (for example, JavaScript) and provides functionality that supports creation of the payment page and/or how the data is transmitted to the payment processor.
As for iFrames vs. Direct POST, from https://www.pcisecuritystandards.org/documents/Understanding...:
Examples of e-commerce implementations addressed by SAQ A include...[merchant] website provides an inline frame (iFrame) to a PCI DSS compliant third-party processor facilitating the payment process...Examples of e-commerce implementations addressed by SAQ A-EP include...[merchant] website creates the payment form, and the payment data is delivered directly to the payment processor (often referred to as 'Direct Post')
SAQ A applies when using one's own server infrastructure, and SAQ A-EP applies when using a PAAS.