One of the most important reasons to use SPs is data integrity. It should be up to the database to maintain its own integrity, rather than the client. Imagine the case where you are deleting a customer with an address. This, with a property normalised database, would involve deletions from at least three tables: customer, address and customer-address (a join table). You should not have to rely on the client to remember to delete from the join table - there is too much risk that you will end up with orphaned rows. You should therefore call an SP that performs the deletion from all three tables in a single transaction. Database integrity applies to all inserts, updates and deletes, therefore I'd recommend using SPs for all DML commands.
On the whole, I'm happy to query directly from the client, except in cases where you cannot be sure in advance how many queries will be necessary. For instance, if you want to get all of the payments made to an account, but for some reason (due to the data model), you are unable to get all of the data that you need in a single query but instead have to do a query for each payment, then the client is going to be making multiple queries to the database; multiply this by x concurrent users, and you end up in a mess. In these circumstances, it is best to use an SP, therefore requiring only a single interaction with the database.
EDIT
SPs also allow more flexible code reuse. Any application, written in more or less any language, can use the SPs. Furthermore, if this is a client database, then if you write proper interfaces (and documentation) to these SPs within a secure schema, the client can write there own applications to interact with the database.
EDIT
SPs are also, possibly, the most secure way of preventing SQL injection