Thanks for the replies. Thom, that caching behaviour you describe catches me out approximately once a month!
I'm glad that you both think along the same lines as me. I can imagine, for example, having a hundred reports deployed and then going through a refactoring exercise where one of the well-used DB columns is renamed. Pretty straightforward to handle when all of your code is in procs, but mighty time-consuming if all of the RDLs have to be checked and (maybe) edited. And after that, the release itself requires additional coordination.
I have not tested this to any degree, but the fact that the code in the procs is compiled should also help performance.
Everything feels more controlled when as much logic as possible is in the database itself ... in the hub of the wheel rather than in several of the spokes. Trying to assess the effects of database changes when code is spread across different systems takes longer and introduces a greater risk that something will get missed.
I would like to hear more counter-arguments though, in addition to laziness! One might be that changes to a report require only an SSRS release, rather than DB + SSRS.
If you haven't even tried to resolve your issue, please don't expect the hard-working volunteers here to waste their time providing links to answers which you could easily have found yourself.