1. Update routines are complex and non - trivial. Many implementations are not able up update the table with .NULL. values or if they do, require all fields to update to be passed having serious concurrency problems. OIW, they have serious limitations in updating records. That first statement is a matter of opinion. Some may feel that way, and others may see that as a non-issue. As for the rest of this point, check out my other post and my blog entry about the mechanics for an UPDATE stored proc that can handle both NULLs and optional parameters.
2. As opposed to remote views, the developer needs to have a list of all update parameters and pass them at the right position, not making updates transparant nor easy. Again, see my other post. Also....pass them at the right position? I don't understand this. I don't believe I need to pass them in any specific order (obviously, I need to have the names right!).
3. As opossed to remote views, SPs in practise tends to be more suspectible to code injection since in practice strings are passed and added to SQL statements to provide certain flexibility in searching and scoping. Remote views, are protected from this kinds of code injection. You can implement searching and scoping with all sorts of parameters - you don't need to pass strings to append to SQL statements in a stored proc to get additional capabilities. You can now pass true XML to stored procs, and you can use CASE and other statements inside stored procs to get "flexibility".
(For the very first time, I think I see why you're saying at least a few of the things you're saying. Look....yes, many people don't use sprocs correctly. But that doesn't mean the methodology is wrong, it's just a case of inexperienced people who don't have years under the belt, using them. By contrast...I've known developers who totally shot themselves in the foot with remote views that were so poorly done, that they often couldn't debug their own problems. But I don't criticize remote views per se...)
4. They are a no go when your application needs to create SQL statements on the fly (application Query engine). Once again, there are things that can be done in some instances to address this.
5. They are a PITA when doing multi table transactions. For example try to wrap an order and multiple orderlines into one transaction. I have to admit, I honestly do not understand why you think that can't be done, or why you believe they can't be done. Between transaction objects, error handling capabilites in SQL 05, etc....this is hardly a PITA. If you really and truly feel this is an issue, I'll post a small sample to demonstrate this.
6. Dynamically created SQL can be written more effecive as opposed to using CRUD Sps as the latter tend to be gereneral purpose where unneeded parameters need to be passed and processed. Dynamic SQL tends to be far more granular, esspecially in concurrency issues. Once again, check out my post and blog entry about unneeded parameters. It's important to distinguish between the way people are doing things, versus the capabilties of the tool.
7. SPs are DMBS specific and their implementation seldomly is ANSI compliant. So if you plan to support multiple databases, you'd better think twice to use SPs. Remote views and/or using SPT might be a better choice. This is the one area where I won't say much. If someone truly needs to support multiple databases, then a company has to make some decisions.
8. Remote views, which create efficient dynamic SQL, provide an easy and totally transparant way of updating your back-end database, just USE it and TABLEUPDATE() and VFP takes care of the rest. Remote views (or updatable SPTs) provide a great way to provide transparancy between local and remote data. OK, fine, they work well for you and others. But how is this a criticism of stored procs?
On your are area of SP mis-use....there's no question that they can be mis-used, especially by people who work on the premise that they are (by nature) faster than dynamic SQL. Whatever performance differences exist between compiled code and other forms, are very very minimal and not worth citing as an advantage. (Note that I never used performance in my list).
