None of the LibreOffice and Qt (including Otter browser and the like) would have been possible without a package manager. And Haiku would still be a toy OS with no office suite and no decent web browser. It was also highly motivating for developers because it’s one of the places where we have shown that the approach we use in Haiku, to rewrite a lot of the software components rather than reuse existing ones if we don’t like them, showed that it can work. The package manager is possible in this way because the developers doing the work could work on the command line tools, the kernel, the bootloader, the filesystems, and also the infrastructure to port packages, all at once, and build a solution where everything fits together. Installing and uninstalling packages is super fast, you can rollback to older states, installing Haiku is almost instant because there are now just a few hundred files to copy instead of several thousands.
The system is not without problems, one is the dependency hell of non-Haiku siftware but no other package manager would solve this, we knew it would happen, and we hope it is only temporary as the ecosystem of native apps grows, but in the meantime we have to provide some usable apps to our users to get things started. The other is HaikuDepot, which tries to be both a package manager and an app store, and fails at both; as well as the Repositories preferences and SoftwareUpdater, which are both not that great in terms of UI design. Both of these issues are unrelated to the package technology chosen.
Switching to something that extracts packages would make installing and uninstalling packages slower, installing Haiku would take much longer, no rollback possible. And yes, users could mess up their systems and make bug reports no one manages to reproduce because they forget they have modified some file, and their changes would get overwritten on updates whereas in the current situation, they are not, instead they are clearly separated in a non-packaged directory.
Also, this has been debated a thousand times on this forum and on the mailing lists before, and no, we’re not changing our mind on it. If you have actual problems with some specific packages, we can fix that (usually rather quickly). If you just have a general feeling that “things would be better if…”, read the original discussions that led to the current design, and come up with a scheme that checks all the requirements and brings something new, without additional performance hit, and then we may consider it.
Sorry, but it’s quite annoying to have this discussion over and over again and always rehash the same arguments.