My educated guess on what is taking place is that the COM Tables are being used to register various COM Libraries in the package.
When your main application calls these, they are used as an entry point into the Windows Installer autorepair, but the application relies so heavily on them, the check that's performed each time the entry point is called causes a performance hit.
When you build your repackager project, there's an Advanced setting in the project that you can disable, "Map registry data tot he appropriate COM tables". If you disable this and rebuild, it will register the COM Servers through the registry table, which is then not used as an Advertised resource, so there's no check when the COM class, types, progid, etc. are called.