was that his deformable terrain engine? pretty impressive, but i think he had issues with speed.
anyway the main problem is this. in a game when you have an object like a ship, what you really have is a description of the ship, with all the parameters for that ship. the actual model is likely a reference to a single copy of a model, which is shared between all ships that use the same model. only thing that is different is the orientation matrix, the position, physics data, names, etc. so when you need to do any geomodding you now need to keep a copy of that model data for each instance of that object in the game instead of just using a model reference (since any changes to the model will affect every instance). so you have higher memory usage. to save memory, you can instead buffer all the deformation coomands, and apply them every frame, which is slow, but you only need to store the information for the object you are working on, once its rendered to the frame buffer it can be tossed and you can process the next one. this can get costly in cpu cycles if the list of commands gets long. this is like the carmageddon 2 example (only the deformation matrix for each object is updated, and it can be multiplied by new deformation matrix and stored for the next impact event, and used for rendering).
back to aardwolf's piece of code i should point out that modifying world geometry is way different from modifiying geometry of multiple objects. since only 1 instance of world geometry is ever used, so updates to that information is less costly than have to track of every instance's deformed geometry.