The ELF shared library system was designed to handle multiple versions.
If you look inside /boot/common/lib, you see that every library has two symlinks pointing to it, e.g:
~> ll /boot/common/lib/libcurl.so* lrwxrwxrwx 1 user root 16 May 9 04:11 /boot/common/lib/libcurl.so -> libcurl.so.4.2.0 lrwxrwxrwx 1 user root 16 May 9 04:11 /boot/common/lib/libcurl.so.4 -> libcurl.so.4.2.0 -rwxr-xr-x 1 user root 311057 May 9 04:11 /boot/common/lib/libcurl.so.4.2.0
When building a program, the linker looks for libcurl.so, finds it, and looks inside the file, which in this case will actually be libcurl.so.4.2.0. From the file, the linker reads the "soname", which in this case will be libcurl.so.4 and this is what the runtime loader will be looking for when the binary is executed later. (See for instance http://tldp.org/HOWTO/Program-Library-HOWTO/shared-libraries.html)
This way, the library can be updated to an ABI compatible version, and programs will make use of the new version without any relinking or re-packaging. When an ABI incompatible version is added to the system, it will be with a bumped soname, so that they can co-exist as libcurl.so.4 and libcurl.so.5 for instance.
Now, let's look at how an application is linked:
The libs that expose APIs from the Haiku Kits don't need it either if the devs plan to never break binary compatibility there (and if they do, they can get around it by renaming the file even if the original name did not imply any versioning).
Curl, sqlite3 and xml2 are found in /boot/common/lib and follow the scheme outlined above. ICU, libpng and libz are from /boot/system/lib, which does not include a symlink for each soname. This is a little unusual, but not a problem. The actual version of libpng.so.1.4 for instance is 1.4.x, so the filename is just missing the minor version rather than being pointed to by a symlink. This means that when libpng breaks binary compatibility, the version will be 1.5.x, and so Haiku may include both libpng.so.1.4 and libpng.so.1.5 at that point if needed.