Actually it meant the "text" segment (code and constant data) was write-protected during execution, and hence could be shared between multiple processes executing the same program. In fact that's why it was called the "sticky" bit -- the text segment could stick in RAM even if the process was swapped out, and in fact never needed to be swapped out because it could always be reloaded from the executable file. This is now assumed in the case of modern paging systems, but in the old PDP-11 it wasn't available on all models and could in some corner cases reduce the total amount of virtual memory available to the process (you only had a total of 8 physical segments of up to 32Kb each, and the stack took up at least 1; later models allowed 16 segments total but 8 could only be text and 8 could only be data or stack). Hence it had to be user-modifiable.
[although you needed a later 2.x BSD to utilise anything beyond 64K code 64K data. 2BSD could do segment handling stuff [think DOS EMS and try not to get flashbacks from the horror]
Now I'm showing my age :-)
The V7 manual doesn't quite agree with you. The sticky bit simply indicates that the code segment for the binary should be kept around in memory/swap (fast storage) not discarded. It might get set on a tiny number of root apps to tune performance.
Anyone who remembers "resident" on the Amiga has the right idea.
It did require on the 11 that the program was split I/D so there was an unmodifiable code segment but that's an implementation detail for that architecture. Some Unixen today still honour the sticky bit for executables - but not many.
As it was only relevant for executables it also got borrowed for other bits. For directories it indicates that only the file owner can unlink(remove) files - mostly to fix /tmp. A couple of systems use it for other 'magic' on non-executable files.
Alan