Packages A and B both depend on shared library C. A critical bug is discovered in package A that requires a change to library C. Package B releases an update to stay compatible with library C. It turns out that the update to B doesn't work. There is no way to revert B to the previous version since this also requires reverting library C and package A to the version with the critical bug.
This sort of thing is why commercial apps try to avoid using system shared libraries where practical. The issue is that you just never know what sort of crappy system you're going to be dropped into. Bundling as much as you can limits the pain a lot, and the cost is just space (and time when downloading, if relevant).
Of course, if nobody ever shipped buggy updates and never broke backward compatibility, you wouldn't need this sort of thing. But on Planet Earth... <sigh>
I still remember the days of "DLL hell" when everyone shipping Windows products included their own version of various, supposedly shared DLLs. The problem was the first one loaded was expected to work with the others which didn't happen since it didn't have the right customizations. Yeah, that approach worked really well.
The problem with avoiding shared libraries is that the onus for keeping up with updates to the shared libraries transfers to the application developer. You still run into the same problem as my example; just the immediate consequences are hidden. If "B" builds in or statically links to an old version of the library, there is still the possibility that there will be a critical update to the library and it's now up to the application developer to re-build it in, test the new build and release the update. It's possible that the critical bug is in a part of a library their application doesn't use but we're now relying on the application developer to make that determination.
Cheers,
Dave