Excellent article.
I tend to agree with Andy, however, because I can also use a couple tables to specify not only which business rules are needed, but the ordering for different processes.
I.E., FICA calculation might be called first for a "normal payroll calc", but second for a "flex spending account calc". Not much different than yours, but if I keep it all in the database, less network and connection overhead. Also, multiple interfaces (VB, ASP, C++, etc), can call the same stored procedure and the logic is maintained without changing multiple clients. Since I tend to favor keeping changes on a desktop app to a minimum, this allows me to make an "emergency" change on the backend without redeploying another front end. Less important for web apps, but I've worked on apps that went to hundreds of geographically distributed areas. Redeploying something because someone decided later at there needed to be two different processes stink.
Not sure I'm being completely clear. I think your method might handle it, and it might be more an matter of opinion on that actual architecture. However, again, a great article and something that people don't often think about.
Steve Jones