In the case of Ruby, it's not really trying to be smart. Ruby loads everything into a single namespace, so loading multiple versions of the same dependency could cause classes, modules, etc. from version 1.1 to overwrite those already loaded by version 1.0. The dependency manager is constrained by the language. The same is true of most languages that I'm aware of, though Java can load multiple versions of the same class.
The biggest problem caused by using multiple versions of the same library is that object representations are not stable across versions. Let's say you use a library "foo" that creates and manipulates Foo objects. You want to serialize them to JSON, so you use the third-party library "foo-json". If you have foo@2.1.0 and foo-json depends on foo@1.9.7 then foo-serializers will likely fail to serialize the Foo objects created by your application. This is why npm supports peer dependency constraints, though usually they're invisible to you as a user.
There are also performance and cost issues associated with using multiple versions of each library:
1. Starting the application requires loading many of those library versions, so you will have higher start-up latency than if you only had one copy of each library.
2. If the target platform uses method-based JIT compilation (e.g. Java), each of those libraries will be compiled independently when it is used. This can cause the application to feel sluggish between the time it initially starts up and the time that all of the copies of the libraries on the hot path have been compiled.
3. The program needs to be loaded into memory to execute it. You're not only paying for more hard disk space, but also more RAM. The additional memory required can start to add up if you're running enough replicas of the application in production.
For many small applications the performance and cost issues aren't major concerns, but they can become problematic as the application grows.