In SQL Server Management Studio you find Schemas under the Security group. The schema that is most often used in the database is Database Owner, or DBO. User access accounts may be granted the DBO schema, or select permissions related to anything owned by the schema. For example, an SQL Login may be granted execution permission to any stored procedure that is a part of the DBO schema simply by granting execution permissions to the DBO schema. That same is true of tables, by granting SELECT, INSERT, UPDATE and/or DELETE Permissiosn to the DBO Schema.
As you can see, organizing database objects makes it easy to grant appropriate permissions to SQL logins, with the granularity defined by your schemas. A user or group may be granted access to many different schemas at the same time. The permissions per schema do not have to be the same.
If you wish to grant permissions to a schema globally, you can individually deny permissions to single objects. This allows you to reduce the amount of work you have to do to provide or deny permissions. You may have noticed that I stated you can grant access to users or groups. This is helpful when your database is using Windows security based on a domain. Multiple windows users may share permissions granted to an Active Directory group, once that group has been added to SQL Server, and permissions assigned to the group.
One of the reasons I like to use schemas is the organization it provides in SQL Server Management Studiio, when working with large databases. Stored procedures are a good example of how using schemas helps organize your code objects. Each procedure has a prefix of the schema to which it belongs. Therefore, all stored procedures are listed in schema order in the object manager. When there are many procedures, tables, etc., this use of the schema can make objects easier to find.
You can have more than one object with the same name, if they belong to a different schema. This is a quite useful feature when working with large databases. One thing that is interesting is that you can create views with the same name, point them to the same exact table, and have them look or behave differently. This allows you to write one set of code using the view, and have it behave differently from one user to the next, depending on what schema they are granted permissions.
Consider using Schemas when your database is quite large, when you have a lot of different security requirements you need to fulfill easily, or when you need to have different behaviors from one user to the next.
Cheers,
Ben