I normally agree with (and am interested in) most of what is written in these blogs but in this instance this is not the case, to the extent that I felt I should respond.
As an architect, as well as a developer, I see significant value in having our applications interoperate with a number of different DBMS types; indeed, it is sometimes a design imperative. In my experience, keeping the interface to them all as generic as possible greatly simplifies the ability to achieve this.
Also, not distributing the application logic into the DBMS has 2 main advantages, these being 1) it is easier to deploy the applications, and 2) it easier to maintain the applications. For point 1: we sometimes have to operate our applications in environments where our database gets slotted into an existing enterprise DBMS. Also, we sometimes deploy to locations where IT cannot or will not bend from their "rules"; often these are of the making of the individual rather than the corporation. Simplifying the database side of things can greatly aid overall deployment, both technically and politically. For point 2: I have seen situations where the extent of stored procedure use and their side-effects have made it much harder to debug problems.
Most of our tables never contain anything like hundreds of thousands of records so performance is not as critical (as for large tables). In any case, I have developed and worked with abstraction (shim) layers that isolate the application logic from the database access and provide a good level of specific DBMS optimisation.
Not only that, but we always test our applications against the largest data installations before we release them (what a surprise). There is always the option to test specific queries and optimise them if required; so, in the end, we always achieve more than satisfactory performance. I have seen stored procedures with poor database performance...
I do not advocate the program oriented approach in all cases, especially if data loads are substantial or the application is being developed for a single DBMS type. I do advocate seeing application development from the development/architecture side as well as the operations/DBA side. If your experiences are only with poorly tested and poorly performing applications then this is a skewed view of the world.