**interpretting based off of prior knowledge of videogame engines -- I'm not an engine developer**
Yea -- it depends on the engine. Though I don't see how that explaination really works.
Essentially what I believe the source is referring to is that the engine needs to know all the end vertices along with the start vertices which will take up as much RAM as if it WERE adding extra polygons. (there's little difference between storing 6 vertices, or 3 vertices in 2 different positions)
And with RAM being the largest concern in videogame graphics right now (due to perpixel lighting models separating vertex count from lighting calls/passes) I can see how your source would assume that extra vertices will cause similar slowdowns to having extra polygons.
There are however certain other issues that need to be taken into consideration:
1) Whether or not the blendshape is baked or procedural.
If the blendshape is procedural -- like realtime lipsyncing... you won't notice the RAM be hit. If its a scripted animation, like something you'd do in Maya -- then you might.
2) The extra vertice data will NOT be stored in VideoRam (except in consoles and lower-end PCs which share RAM with the videocard) -- the GPU doesn't animate, the CPU does all that crap... so the GPU RAM should only have the endstate vertice data. This of course assumes your engineer isn't stupid and places non-rendered clones in VideoRAM wasting valuable megabytes for something which will never appear.
3) There's no proxy or bone animating the blendshape -- if its Maya-style blendshape then it probably would take up the RAM as if it were the extra amounts of polygons... if they group vertices somehow (bones/proxies/parenting/what-have-you) then there would be no RAM limitations -- it would only need to set rotation/animation data per-bone/proxy/parent and interpret via weights and the likes what the vertices should pull to.
Basically -- in many cases... yes it should suck up as much physical (system) RAM as adding the extra polygons, but shouldn't waste lighting/shading calls though.