because build scripts have hard-coded, absolute paths
We usually define these paths as constants in a config file (e.g. LIB_DIR, STATIC_DIR, etc.) and then use the constants in the rest of the code so that if you need to change it in your dev environment it's easy. It also makes it easy if we wanted to move those directories completely (e.g. to a different mount).
I definitely shouldn't have to check out my source to a specific path like /home/coworker/projA in order to compile it. That's just wrong. But the contained output, a .rpm or .deb puts libs in /usr/lib, binaries in /usr/bin; some path that's hard coded, and totally should be.
You're totally right on the path to the source code. The build scripts, as typically run by a developer, should actually do two things: 1) build the code into binaries and 2) deploy those binaries on the developers machine so he/she can easily test it. Builds on official build machines shouldn't be putting the builds into the hard coded location, and so shouldn't do the second thing. I haven't started discussing the difference between build scripts and deploy scripts, but that's essentially the difference I'm referring to here.