I would strongly advice against placing any business logic in a stored procedure. However, there might be a case (you listed two fine examples) where it is preferable to place data access logic there.
Generally speaking, if you feel tempted to use SP's it is a sign (a code smell) hinting that your data model is not well suited to its needs.
Edit: When developers ask me about business/data access logic, I say that business logic is about how data behaves and interacts, while data access logic is about how data is stored and retrieved.
For exemple: In your domain model you might have the entities "Student" and "Teacher", both derived from "Person". (Not saying this is preferred, just an example). This can be stored in a relational databas as one, two or three tables. The choice depends on how many properties they share, and on read/write performance requirements.
In Business logic it should not matter how those entities are stored. (or wether they reside in a RDB at all). Data access logic is all about how they are physically stored.
So, regarding the original question: If a stored procedure makes storing and retrieving data more efficient (or more robust) you have a case. If the stored procedure is merely for imposing a rule that i valid regardless of how data is stored, avoid it. It makes your code more tightly coupled to the database.