Some Steam shortcomings that I hope they work out:
Let me jump into the discussion...
I understand the reason why they decided to go with Ubuntu (and hence .deb), as it is the percieved most widely used distribution, and also it is the upstream to a bunch of derivative distributions, even though it might stem from Debian itself. I agree with what others have stated about LSB, and as such I do reckon that "as part of LSB it would make more sense to go RPM", however a few .rpm based distributions have had traditionally differences in how they name their packages, etc... The way I see the package manager and dependency resolution problem would be to instead of relying on the distribution's package manager (apt, yum, etc) to abstract the dependencies to individual files (i.e libstdc++-6.0.so <i686>) and parse them to package-kit which would then use the local package manager to locate the appropriate package to satify said dependency.
Moving towards a more distro/package manager neutral dependency management (the way I understand it, any way) would necessarily go through PackageKit.
As to the "best" way to install Steam, I don't see any problem with it being a self-contained archive installable somewhere in the user's home directory or through package manager, in the end the behavior is the same as say GIMP, Mozilla, wine and other products: Have the core libraries installed system-wide, and locally needed files locally (by means of the currently used ~/.local/share/Steam/ path for Steam), and in such a way even that it could behave like some games in such that in-app updates override the system-wide application version, if say the system package managed version is not in sync with the in-app version. Some games allow this in their /main/directory Vs ~/home/.game directories, making the necessary adjustments in the launcher scripts by use of checks to assess the system Vs user's home directory versions of the components (with 'if' or 'case' statements).