That was my first thought too, hence the memory_limit=-1 switch in my command. If I'm not mistaken, this should override any other memory limit.
Anyway there is no memory ballooning in the system during the 2 hours it does its processing, so I feel that not to be the case.
For what it is supposed to do, it seems a bit strange the way it seems to be working, because no physical object data is pruned whatsoever. Correct me if I'm mistaken, but the way it should be working is:
Take a physical location record, check in the i18n table if there is another (older) one with identical values in the container name, location, and type. If that is the case, locate the relations that the duplicated physical location record has and copy them with the older physical location as target before finally deleting the duplicate record.
So, this should be constructed as a loop working on a physical location at each time, but it seems to be building some kind of structure to perform all the changes at once, hence the extended time and lack of changes that I'm seeing.