It's a matter of scaling. If your job is "I want to run MongoDB," then it makes sense to track MongoDB's repo. If your job is "I want to run 100 different applications," then tracking 100 upstream repos (and dealing with their usually 80%-competent jobs of handling library dependencies, etc.) is no fun.
I happen to be in the latter position. Developers at both my employer and my previous employers generally cannot just install whatever they want, mostly for longevity/support reasons (at my current employer there's a way for developers to import outside code into the monorepo, which means just this week I'm cleaning up Node 0.10 and Go 1.3 from the monorepo...). They go through a team that builds them a system they can use. And that team strongly prefers to get software from our Linux distro than from third parties, because every single team has their own preferred third parties to get software from.
I do agree that for a shop that's running a single big web application with Mongo as the backend, they're probably installing it from upstream (and happier with that), but that's not the only use case.
I happen to be in the latter position. Developers at both my employer and my previous employers generally cannot just install whatever they want, mostly for longevity/support reasons (at my current employer there's a way for developers to import outside code into the monorepo, which means just this week I'm cleaning up Node 0.10 and Go 1.3 from the monorepo...). They go through a team that builds them a system they can use. And that team strongly prefers to get software from our Linux distro than from third parties, because every single team has their own preferred third parties to get software from.
I do agree that for a shop that's running a single big web application with Mongo as the backend, they're probably installing it from upstream (and happier with that), but that's not the only use case.