Maybe I misunderstand, but don't you want to invalidate the cache when a new version comes along? Isn't the risk of version skew worse?

If one.js changes but two.js doesn't, then two.js should come from the cache. Only one.js should be fetched from network. Sticking all assets in an /assets/v2 folder invalidates everything.

If one.js and two.js are really separate components, they should each get a version. If they're closely coupled, they should be compiled together into one unit, to take advantage of deduplication, inlining, dead code elimination, fewer requests, better compression, etc etc.

Versioning assets separately by sticking them in new subfolders is just re-inventing ETags in a bad way. Just use ETags.

The point of the folder versioning scheme the article proposes is to make rollbacks easier. You can easily rollback a /assets/v2 folder to /assets/v1 by updating your server template, but if you have a dozen separate version folders (with different latest version numbers) for each resource then it's no longer easy to roll those all back.

That's fair. Most apps I have worked on have very few bundles of JavaScript that we either served inline or in one request, but I can see how this helps in the case of many requests.