The long answer is simple: the more responsibility you put in Stream, the more complexity you get.
The first complexity that I'm speaking of is non-uniformity and random implementation (or un-implementation) of a set of features.
I mean some streams in the huge hierarchy implement only half of the contract, but hey, what was the contract exactly?
Ah, yes, there were no contract, just hacks left here and there randomly and concurrently in a big hierarchy.
I add a new subclass, but don't implement all the features, there are too many of them, and I don't know them all..
I add a new feature, but don't implement it in all the classes, there are too many of them, and I don't know them all.
This procedure invariably ends up with a blob of un-maintanable code, were two stream would not even agree on upToEnd behavior - I think you remember it :)
If the goal is to replicate all the accumulated responsibilities of Squeak Streams, but with a clarified contract, I think this is a dead end: too much cruft to support, too many features, too many undefined or not well defined behaviors to be clarified.
Xtreams takes the opposite path: concentrate on constructing a common, simple and uniform API, concerning streams, just basic stream methods.
Some specialized streams then implement some specialized behavior, and you can compose them (by wrapping) when you need the specific API.
This way, you ain't got to implement/maintain feature A into a few dozen of classes.
And your brand new SpecialFeatureBStream only has to implement a few well known behaviours and your Special Feature B.
The short answer is even more simple : a stream does not have a name, like a collection does not have a name, because we ain't gonna need it.
If we really need a name, then we'll create a XTNamedReadStream and a XTNamedWriteStream responding to #name, but I doubt we'll do.