These dynamic linking technologies have been superceeded in XCode3.0 and greater.
Dynamic linking provides a mechanism to share libraries. The standard C library may be used by most applications so statically linking, essentially compiling those functions into each individual application, is very inefficient.
To allow dynamic loading (often seen as .dyld) the compiler leaves library method calls as stubs. During application launch the dynamic loader parses the stubs and either replaces the stubs with libraries already in memory or loads the library as required. This extra overhead during launch takes time, so prebinding and zero link were devised to keep the benefits of dynamic linking but reduce launch time.
Prebinding involved pre-allocating memory addresses for libraries where each library author would define a memory address unique for that library. A prebound application using prebound libraries during link time would assume those addresses so at launch time all linking is done, resulting in a faster launch time. Since OS 10.3.4 the dynamic loader was optimised to the extent of being at least as fast as prebinding.
Zerolink approached the issue from a different angle. An application built with zerolink would only link enough to get the application off the ground. Only during runtime as unresolved symbols were found would linking occur, as required. Again the time saving involved is no longer beneficial due to the optimised dynamic loader.
In XCode3.0 and above there are still build options for Prebinding and Zerolink but they are ingnored. They are only present to allow sharing of projects with XCode 2.5.