One of the big reasons I prefer SPs is management issue of data access across all applications (which might be written in different tools) hitting the data. The code management issue will usually scale out better with SPs.

I cut my C/S teeth in environments with multiple vendors, generally with one vendor that "owns" the database. Yes of course that vendor has to control access to the database if they are to support their own product- if other vendors can screw data, it may be impossible to support. Classically this control is achieved using SPs, or Views in the case of Oracle. However, the current scenario is a read-only select case. One might argue that the support issue is of little significance in a read-only case and that most vendors are capable of putting together a read-only select without needing daddy to give them a SP. ;-) However, IMHO a SP still makes sense if some of the data is sensitive (pricing, patient records etc) or table/index structures mean special techniques are needed to get the best of it, or if some of the inside stuff is really special and carries your competitive advantage... yeah I can think of lots of reasons. FWIW, in Oracle you could offer a set of Views customized with allowed/needed data for each vendor , with joins in place to prevent bozos creating unjoined queries that return billions of records. ;-)

But code management across apps? I don't get that at all. Surely the purpose of a multi-vendor/app scenario is that no one vendor has all the niche expertise. In such a case, surely extracted data is just the fuel for the smarts that follows? A vendor with lots of clever technology may not be keen to hand it to you to include in a SP- actually they may prefer to download data and munge it locally. Possibly even using a naughty tool that specializes in such behavior. ;-)