I'm a proponent of schema for both security and organization.
Our design for data access and manipulation is fairly straight forward. the R part of CRUD is done via views and the CUD part of CRUD is done through stored procedures.

Schemas facilitate this nicely, our tables sit in different schemas than our views, procs, functions...
i.e. We create tables in a data schema (typically named [data], [config], [audit] and others relevant to the solution such as [customer], [engineering] etc), then we create views, procs, synonyms etc in "role" schemas such as [app], [service], [bi], [security] etc). We don't assign any permission to the data schemas, rather, using AD Groups, we assign SELECT, EXECUTE and VIEW DEFINITION (as needed) to the appropriate schema(s).

This has been very effective and it's encouraging that you're seeing more usage in the schema direction.