Stored procedures (code stored and run inside a database) are still considered a good - no, great - idea by plenty of developers.

Some reasons:

1. When you put application logic (business rules, complex transaction code) in the database, it can be accessed from any other component of your application (front end UI, backend batch processing, etc.). The higher you move that logic, the more likely it is to be duplicated - a serious problem for maintainability and bug fixes.
2. You can achieve better performance for your users. It’s not just a matter of network traffic (though I do disagree with Greg Kemnitz on his dismissal of this factor). It’s also a matter of context switching between the database and other components of the application. The most common - and serious - performance problems many developers face is row-by-row processing of data. This is more likely to occur when you don’t take full advantage of your database - especially SQL/relational databases - and move all your code out of the database.
3. Improved security is a big plus. With languages like Oracle PL/SQL, you can encapsulate all data access being package-based APIs and apply a level of security (including eradication of SQL injection issues) that is simply not possible at an application level.
4. Your UI language is far more likely to change than your database. If you make full use of stored procedures, when the UI changes, all you have to do is re-hook up the UI data access points to the existing, unchanged data API.

I hope this offers some counterpoints to consider.