Yeah, at some point it needs to be decrypted, but the idea is to push it to the last possible moment, and to only allow access to whichever party actually needs to make the charge.
I don't see how that changes things at all... The payment gateway still gets the info, you still need to enter the info somehow, and in most proper e-commerce implementations these days they don't have access to the cc # anyway.
What changes except adding more work/failure-states/encryption at the one point where it does not matter?
I agree that for most implementations, it wouldn't make much difference. There's no point in trying to hide a cc # from Stripe, since they need it in plaintext to make the charge anyway.
But the use case of VGS as described in the article is for companies that do want to charge the cards themselves or otherwise access the cc # for whatever reason vs. outsourcing that. In this case, VGS allows you to hold a token instead of the cc #, and then you can trade your token in for the cc # (alongside some other authentication probably, like IP restrictions/anomaly detection) to make the charge.
I'm not an expert on PCI, so I don't know whether this approach truly satisfies it in itself since yes, the tokens are still sensitive. But my point is that if you're going to take this approach, and believe it does satisfy PCI, then it's strictly better if you don't have to trust VGS to store the cc # in (effectively) plaintext.
Encryption is one part of PCI (data stored at rest and in transit). There's still a slew of controls that need to be satisfied when you have access to the data and there's no getting around them if you chose to take this burden on yourself.
The technology involved in persisting sensitive data on disk is a small portion of becoming compliant.