The use of schemas is common in Oracle because small "databases" in Oracle tend to be implemented within a single instance, each owned by a separate schema. This, along with public synonyms hide most of the complexity of this from the user but still make maintenance for the DBA more straightforward and helps with understandability (is that even a word?) for developers.

What I see with Access apps that have been "upsized" to SQL Server is a similar siloed approach, but that pigeonhole the data into a bunch of small databases (absent active intervention from the DBA) instead of several schemas within a database. An even worse approach for the administrator (in this case, me).

I think once SQL Server "Yukon" gets synonyms and a proper schema implementation people will warm up to them. As an example, think of the [sysobjects] table as being owned by [sys] with a name of [objects]: [sys].[objects] and you'll see that the good folks at MS have been working around this issue for some time, and so have most of us. We have a huge reporting database on a reporting server that is a subscriber to dozens of publications from several SQL Servers. Most of the tables have prefixed names in a sourcesystemname_tablename format, so why not use schemas instead? They would make the identification of related datasets a lot easier, and the security model on top of schemas is also much more straightforward that what we do in SQL Server.

My two cents...