That set of traces appears to be related to COM instantiation based on "advertised" COM classes. Without knowing anything about how your MSI is organised into features, components and COM registration it's hard to be completely sure.
But anyway, if the COM classes are registered using the Class table in the MSI file then they have an InprocServer32 registry value (NOT a key) called a Darwin descriptor. It refers to the target of the COM instantiation through feature name, product code and component code, and that could be why you're seeing references to Windows Installer feature and component keys in the registry. There's typically a call to MsiProvideComponent with that descriptor, resulting a resilience check and a repair if anything is broken.
You don't say what tool you're using, but if you have a lot of COM registration and it's all advertised via registration in the MSIs Class table that could be the issue. Without knowing what tool you use to the build the MSI and seeing the MSI file it's hard to be sure. But WiX, for example, lets you use the Class table for registration but use Advertise=no, and that results in the registration being done using registry entries, which is the fairly obvious other way to create COM registration while avoiding advertising/resilience checks.
Also, perhaps most importantly, you need to make sure that your product install is not in fact repairing itself when it starts up - that would slow it down a lot! If, for example, any files or registry items are deleted after being installed a repair could kick in. Look for MsiInstaller event log entries, in the Application event log referring to missing components.
