I think that the "package explosion problem" actually does exist in C/C++ and Go but it's just hidden. Very often a project takes the form of various components, and you only depend on a subset of them. In these older-style languages these are all shipped as a single unit, but in newer languages these are shipped more explicitly so you can see what the shape of your dependency tree really looks like.
Boost is a great example of this, since it does a ton of different things, but the boundaries between components are not quite as obvious as having a "dependencies.lock" to look at. Tokio has a ton of different packages but often you only need a few of them.
Also often dependencies can be hidden by depending on a single system library, but that then internally contains a ton of stuff. Let's be real about dependencies: https://wiki.alopex.li/LetsBeRealAboutDependencies
The other thing, which is also a double-edged sword, is that "system dependencies" on Linux (generally) have only one version installed at a time and that version is expected to be suitable for all dependents. Distro managers/packagers often put in nontrivial work to make this happen. So you often install something new with few apparent dependencies because the rest are already installed. With dependency locking in Rust etc., you'll often "re-"install the same package many times because the version is slightly different than what you already had.