I have been of the impression that it comes down to a balance, yes in a perfect world, every class that every developer designs would be abstract, and have separate layers on every project.
But we don't live in a perfect world and I believe it comes down to money. The layered approach may be ideal for projects that are highly likely to be scaling out in the future (i.e. You could have one box that runs the data tier, another for business logic etc). But if you are doing a smaller project that is not designed to be scaled out on a large scale then maybe the layered approach is overkill.
The golden rule whatever you do is documentation, if you leave clear documentation on the architecture of a solution then that helps more then anything.

This is a common practice. Many places, including Microsoft, separate their namespaces in this manner. In a project we just completed, we had a Data layer, Business Object layer, and Mapper layer, all of which existed in different namespaces.
Then, there were webservices that exposed similar functionality as the Data layer (and actually used it internally) that was named slightly differently, though the actual name escapes me.
As a company, we can reuse these very easily, and another developer coming in afterwards has some idea of where things will be located. In the long run, this is the better approach, and saves time (and for us, time is money).
One other note--all classes can't be abstract...no one would ever get any work done! :P
Good luck!