I would like to play the devil's advocate.
I don't really think there is any doubt that the "best way" to use SQL Server is to do all data updates through stored procedures, but there is an important trade-off between flexibility, development time and the "best way".
A lot depends on the precise situation and objectives: scalability is a major issue, as is return on investment.
I am actually doing a lot of development work which just breaks every rule I've seen on all the discussion forums I've been following in the last few years. Dynamic client side SQL, bound controls (e.g. combo boxes which get populated at run time from SQL tables), form/subforms in Access clients, and so on. On the whole, things are working well and productivity is high.
I can remember how stupified I ws the first time I opened the stored procedure window in SQL Enterprise Manager and got this "type your code in here" Window without any kind of wizard or graphical tool for even the simplest DML operation (this was a shock for me, I'm used to working in Access). Access 2000 doesn't provide anything better for working with SQL SPs, a big disappointment, I hope to find something in Access XP.
I have recently used the freeware version of Lockwood's Proc Blaster, and it has certainly contributed to reducing my reluctance to use SP's, but I still find that using bound controls in Access forms is the most productive solution and I can sure as hell write code which handles updates through recordsets much faster than I can write code for handling SPs (I just can't believe how complicated managing the ADO commnand object is).
OK I am talking about low numbers of users and low volumes of traffic, and a fairly relaxed security situation. So why am I using SQL and not just Access? The benefits are incredible, even for small-medium sized operations, where the problem is often not the number of users or transactions, but the number of applications.
I think your article is very well written and I will certainly refer to it and make the developers who work for me read it, and I will certainly be trying out the other tool that you referred to in your article. Don't you agree that we need more tools for creating SPs (and the VB code to use them) semi-automatically?