Actually, it has been debated to death. ;) This looks better:
SPACE = ' ' SPACE.join(aList)
That reads good to me ("space-join this list") and that's how I always write it.
I just did a quick scan through the 1.5.2 library, and _most_ occurrances of string.join() are used with a string constant for the second argument. There is a whole bunch of one-arg string.join()'s, too. Recommending replacing all of these (not to mention all the code "out there") with named constants seems plain silly.
Sure, " ".join() is the most "logical" choice for Python as it stands, but it's definitely not the most intuitive, as evidenced by the number of times this comes up on c.l.py: to many people it simply "looks wrong". Maybe this is the deal: joiner.join() makes a whole lot of sense from an _implementation_ standpoint, but a whole lot less as a public interface.
It's easy to explain why join() can't be a method of sequences (in Python), but that alone doesn't justify a string method. string.join() is not quite unlike map() and friends: map() wouldn't be so bad as a sequence method, but that isn't practical for exactly the same reasons: so it's a builtin. (And not a function method...)
So, making join() a builtin makes a whole lot of sense. Not doing this because people sometimes use a local reference to os.path.join seems awfully backward. Hm, maybe joiner.join() could become a special method: joiner.__join__(), that way other objects could define their own implementation for join(). (Hm, wouldn't be the worst thing for, say, a file path object...)