Engineering tradeoffs are always tradeoffs. One is not strictly better than the other from the user's perspective.
Mandating shared dependencies means that Debian is often running software against a dependency version that the original author did not develop against or test against. Sometimes the Debian package is effectively a fork. This results in Debian-specific bugs which get reported upstream. Distribution-specific bugs are a crappy experience for upstream developers because it wastes their time, and it's a crappy experience for users to be told that their software cannot be supported upstream because it's a fork.
Maintaining a huge repository of forked software is also an enormous undertaking. It's common for Debian users to be running fairly old versions of software. This is also not ideal, particularly for desktop users who read upstream documentation and require support when entire features are missing from their antique Debian version.
You seem to assume that Debian users are hapless and are ending up in these situations by accident. That's not true. Most users choose Debian's model because they want to use software maintained by people who care about their use cases. They use old versions of software by choice, because they want a platform that doesn't change under their feet. Others use Debian or something Debian-based because it is popular, but it is popular because of its quality as a direct result of making these choices, not despite them.
If you're an upstream who gets frustrated by Debian users, then it's worth considering why they're using Debian the first place.
There are some users who don't want this, and they tend to be the vocal minority. Debian is not the right distribution for them!
I was a contributor to a small Linux desktop application ages ago. We absolutely had a regular flow of hapless users who installed the Debian-provided package and reported bugs that either never existed in upstream builds or had been fixed months before. I believe the situation was that Debian had packaged an obsolete version of the software for stable because of a misunderstanding of the versioning system. When upstream discovered the mistake and contacted them, they refused to update it to a modern version. Instead, they requested that we maintain their fork and backport literal years of fixes.
This situation resulted in Debian distributing a broken version of our software for several years. I did not come away with positive impressions of their packaging processes.
Mandating shared dependencies means that Debian is often running software against a dependency version that the original author did not develop against or test against. Sometimes the Debian package is effectively a fork. This results in Debian-specific bugs which get reported upstream. Distribution-specific bugs are a crappy experience for upstream developers because it wastes their time, and it's a crappy experience for users to be told that their software cannot be supported upstream because it's a fork.
Maintaining a huge repository of forked software is also an enormous undertaking. It's common for Debian users to be running fairly old versions of software. This is also not ideal, particularly for desktop users who read upstream documentation and require support when entire features are missing from their antique Debian version.