Correct me if I'm wrong, but I thought the whole point of Stripe's JS setup, Braintree's transparent redirect, etc. was that it takes your server out of scope of PCI compliance. Basically my server doesn't "store, transmit, or process" any credit card information (the customer's browser sends it straight to the processor), so it's not within the scope of PCI compliance. The author even hinted towards this in their post.
What Stripe does is a gray area, but something you can be pretty sure the PCI Council will eventually clarify so that these things are clearly covered. They may or may not be now.
Why will it be? Because whether the form submits to your server or to someone else's server is irrelevant. If you have not secured your own server, then someone can redirect the target of that form, or inject their own Stripe-style code to silently send the form contents offsite the same way Stripe does it. And nobody will be able to track down the source of that breach because the site owner is probably not complying with the access control and logging requirements either.
Do you really want people that can barely configure WordPress responsible for the security of your credit card number online? That's the effect of not putting this practice under the scope of PCIDSS. That's probably why the banks underwriting Stripe told them to put the requirement that all their users comply with PCIDSS into their terms of service.
If you want to be outside the scope of PCIDSS, then don't host payment forms. Either redirect to a hosted page, or embed an iframe. Either way, being on a different domain means your own security practices can't compromise the payment data.
I asked stripe about all this in their campfire chatroom last night, and I was hoping they would chime in on this thread, but let me pass along some of what they said.
Their response was similar to what the grandparent articulated: that by using Stripe.js, you're avoiding the storage requirements and thus don't have to do anything extra for PCI. However, you can also interact with their API without stripe.js, which is where you would need PCIDSS and thus the language in the terms.
Now, all that aside, I think you bring up a great point about the gray area and the risk that a security breach would cause. One major difference is that with Stripe.js, a security breach would not put at risk all cards used in the PAST, the way storing them yourself would.
A malicious entity who seizes control of your page rendering could replace the javascript, sure. They could also replace the iframe loading code. I don't see why one would be any more or less of a risk than the other.
A full browser redirect will at least show a valid certificate in the URL bar and alert (savvy) users to shenanigans... assuming the user understands that "Stripe, Inc" is a legitimate payment service. Which they almost certainly don't, so the attacker just needs a (free, easy-to-obtain) certificate for any domain that looks plausible.
The underlying problem is that the trust model for credit card processing is fundamentally broken. There really aren't any rules - at least related to the technology for rendering a "type in your cc #" form - that can fix this.
