Slamd64 uses /lib64 and /usr/lib64 for 64-bit libraries, and /lib
and /usr/lib for 32-bit binaries.

There are several reasons for this (in no particular order)

1) It is what the relevant standard, the FHS, says
	(http://www.pathname.com/fhs/pub/fhs-2.3.html#LIB64)
2) It increases compatibility with 32-bit binaries - it is fairly
	common for programs to have hardcoded library paths, especially
	/lib/ld-linux.so.2 (which must be 32-bit for 32-bit binaries to
	run unaltered).
3) It increases compatibility with 64-bit binaries, such as the NVidia
	driver installer, in a similar manner; these are frequently made
	with deference to the standards, with a fixed reference to
	/lib64/ld-linux-x86-64.so.2.
4) It increases compatability with 32-bit Slackware packages - in many
	cases, a 32-bit Slackware package can be installed with no
	modifications on Slamd64, and it will work.

Additionally, there is a "cleanliness" argument, which is subjective.
My reasons for believing this is the cleanest practical method are:
- No chroot, LD_PRELOAD, or similar hacks are needed to run 32-bit binaries;
	they `just work'
- Due to 2 and 3 above, there must be at least one 32-bit binary in /lib,
	and at least one 64-bit binary in /lib64. Keeping 32-bit and 64-bit
	libraries entirely separate, as opposed to having a mix in each
	directory, seems much cleaner to me. Symlinks are sometimes used
	to make it so that the actual binaries are separate, however, this
	seems more like telling yourself that there's not a problem, as
	opposed to actually addressing the problem.