MSI Repackaging vs. Import
In most of the cases repackaging an MSI is bad practice and should be avoided. There are however situations when a MSI must be repackaged to get as output the desired installation package.
Disadvantages of MSI repackaging
MSI packages contain internal references that are not captured by a repackager. These references play a major role in the MSI support of self-healing. Another important aspect is the installation of a patch (MSP). If a vendor is to release a patch for their MSI, this will no longer work on the MSI you generated after repackaging, because all the patch rules will have been broken.
Alternatives to MSI repackaging
The recommended approach to customize the installation of an existent MSI is through the use of transforms (MST). From a transform you can add, delete or change any items you wish.
Another method is to import the MSI. This should be done only if you have major changes to perform in the MSI, that are not supported through an MST.
When to repackage an MSI
This should be done if the MSI package contains custom actions that change the machine resources (generate/edit files, registry, environment variables, etc...) and you want to build an App-V package for it or if you want to convert your Win32 application to UWP.
App-V and UWP packages do not support running custom actions. MSI packages usually contain two types of custom actions, those that are used to prepare the UX during the installation and those that configure the machine by programmatically changing its resources. A repackager automatically discards all custom actions from the MSI, but keeps the effects of the custom actions that change the system, which is exactly what you need in the App-V and UWP packages.