Gotta say I like using schemas for objects. The majority of objects remain dbo of course but some cases come in handy because we can group the objects and assign access to the schema rather than each object. We've been known to use the following schemas:

1. ETL - all objects (sprocs, functions and tables etc) which are ONLY used by SSIS for the ETL processes

2. DBA - all objects which are ONLY used by DBAs - generally sprocs/views/function but sometimes tables too

It just separates the application objects from those used for specific purposes.

It makes using .Net code generators a little easier and yes, they could just be prefixes but that would mess up our naming standard ie that every object is prefaced with the main entity. This way, if I list objects by name I know which entity it relates to regardless of it's function and if I sort by owner then I can clearly separate which objects are used by the app (ie dbo), SSIS (etl) and us (dba). And because the application specific objects are left as dbo there are none of the ownership chaining issues.

All round it works well.