This is a good, quick study on the pros and cons.  I  have written
both application server stored procedures and database stored
procedures.  There are two things I would like to point out that are of
importance.

 Quite often, DB SPs are written poorly, with poor
exception handling that leaves the calling method guessing as to why
there is an error.  By handling exceptions well within the stored
procedure, troubleshooting can be made many time easier.  Along with
the input parameters required for the SP functionality, I typically
have an argument that simply returns success or failure (a code), and
then a string parameter that is descriptive as to what the problem was.

Regarding multiple code bases, it is true that you are now
locating logic in multiple places.  Sometimes, though, stored
procedures are called from multiple application servers which each have
their own code base (completely seperate projects).  In this case it is
surely better to keep the code in a single location (the DB) and only
have to modify it once when underlying DB objects change or the
functionality of the SP changes.

wrt David@tokyo's comment about dbs being boring...  I LOVE em!