I agree with this article - security tops the list when building and maintaining data for our users and ourselves.
From a database developer viewpoint, I prefer to require all table (and even view) access be done through stored procedures. Reason being, in time, things change. An excellent design of a table and it's appropriate indexes (or indices???) along with partitioning, and a myriad of other properties of the table doesn't mean it will always be a good design. People add functionality to a computerized system and jury-rig stuff into a table, the amount of data in a table may grow too large for the original design, etc. Bottom line... something changes in the database which makes the original table (and view) design inadequate. With Stored Procedures, you can add columns, delete or rename columns, or use a different table object, or even create a view that is used by the stored procedure. All you have to do is change the Stored Procedure and the other layer in your project (business layer or front-end) don't need changed. Nothings perfect, but we can strive for perfection.
It's been around 20 years since my initial training on database theory and terminology, but I believe this helps support the ACID acronym.