I don't see how this is any more of a headache than making sure that table changes are all synchronized with the external code. If you change a table, and then change the wrapping stored procedure, this has to be matched with the external code, natch. If you change a table, and the wrapping is in the external code, you still have to match the changes. No real difference there that I can see.

Option 1: Change the table. Then the view. Then rollout code.

Option 2: Change the table. Then the view. Then each stored procedure. Then rollout code.

Both options add complexity. But the second one adds somewhat more because you have more pieces that got changed.
We do things a bit differently here: 4 environments, 3 of which (test, qa, prod) can be seen by clients. Every night dev, test and qa are rebuilt out of the source code control system using an automated SQL loading tool that ensures that the database is consistent. Since clients are in qa all day long, we catch unintended aspects of the system like you mentioned. Production roll-outs can therefore take the whole system down at once, replace everything, then come back up without inconsistencies. We don't have an absolute requirement for 24x7 operation; I assume we would have a mirror system to update, then flip a switch when we needed to convert, if that were the case.

Our requirement for 24x7 is somewhat soft. We sometimes take down the system for an hour or two for database maintainance tasks that are easier done offline.

However we don't like scheduling any more outages than we need, since the system is always doing something. During the day (we have long days since people are in different timezones accessing us) we have people on the website. At night the website is quieter, but we send emails out.

As for simulating usage, given what we do, it is hard for us to come up with a realistic mix in QA that matches the variety of random cases that thousands of people using the site provide.
And if you have multiple developers connecting to the same database, you can't have each one with their own versions of things.
Seems to me this would be an argument for putting the wrappers in stored procedures. :-)

We're talking past each other. What I'm saying is that stored procedures prevent people from keeping their private development completely private. Which is a strike against stored procedures.

I think that you're saying that if you can't keep development environments private, then that is an argument for pushing people to not even maintain the illusion of trying to do so. Which logic, taken to its logical conclusion, suggests that all developers should be working on a shared server, editing a shared source-code tree. Which is an obviously absurd conclusion that I hope you don't advocate.

It may well be that what I think you're saying is not what you meant. In which case I'd appreciate clarification.

Cheers,
Ben