In asking that question, I suppose I’m implying that it matters where developers keep their checked-out source. For some teams it matters a great deal - they cannot build their code without having it at a specific location, because build scripts have hard-coded, absolute paths. For other teams, it doesn’t matter at all, and every developer puts it in a location that seems right for them.
Actually, if you know where the devs on your team keep their source code, you’ve failed. But if you don’t know where they keep their source code, you’ve failed too. You should know where the code is likely to be, but also know that it need not be there.
What you really want is for the code and build scripts to work independent of location, but have a team convention for where it goes. By making sure that the code and build scripts are independent of the path, you make it easier to set up a build machine, which may have many copies of the source code, depending on how builds and releases are managed. You also make it easy for developers to have multiple enlistments, or copies of the source code, on their machine for development purposes. And if you ever need to do some one-off stuff it shouldn’t be too painful.
On the other hand, a convention for where code is placed can grease the skids when working with other developers. If you do any pair programming it’s very important that each development machine have the same directory layout for both code and built files. Even if you don’t, there will be times when you need to help another developer, or debug an issue that only occurs on someone else’s machine. Having standard locations for the code can grease the skids to doing this kind of work.