I know PCI level 1 is more towards those who do 4 mil. + transactions, not sure on the others as I'm not a banker or someone heavily involved in it. I've never been aware of a transaction class for them, though, just more so what you intend to do with the data.
What Stripe.js does is send the card data directly from the browser to Stripe's servers, without the server Blesta is installed on ever seeing that. It then returns a token/hash of the data that Blesta can store in the database without ever knowing what the card data is. This is why Stripe created the JS library, so that it's client->server instead of client->server->server. From my previous experience, once any bit of card data (last 4, cvv, etc...) touches the server that Blesta is on, it has to conform to PCI regulations, because its still sensitive information.
Blesta still stores some data. IF the data is encrypted, then it helps tremendously, but that requires that the last 4, cvv, address, etc...(whatever it stores) is encrypted. But, with how Blesta works now, that data in its completeness is still passed to Blesta, which means now the user has to at least conform to level 4 or 3.
Yes, network scans and such are still required even at level 4, though they are not as intrusive so to speak (takes a lot less to do than say a level 1 scan).
The whole argument here, and what has I believe been presented before, is that Blesta sees the card data (full PAN, CVV, etc...). Even if Blesta doesn't store it all, it still stores some and thus needs to comply with PCI. Using something like Stripe.js changes that so Blesta doesn't have to concern itself with meeting PCI and it can just store a token that it can then pass to Stripe and Stripe can map it to card data.
Basically any servers that see card data need to comply to PCI. A token isn't card data. You can still retrieve the last 4 and all that via the token. It just takes an API call.