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.
