I have been an application developer since the late 1970s. I have also been doing my own DB work since the late 1980s. I agree 100% that stored procedures (SPs) are the right way to access data. If a case can be made for a specific use for in-line SQL, then fine, but I see that as a case-by-case decision, not suitable for generic guidelines.
I also prefer my SPs to do little more than CRUD operations. I stay away from triggers as much as possible. Business logic belongs in the application (IMHO), not in the database, unless a solid case in the context or performance, scalability, and maintainability can be made for a specific use case. That also makes the DB more scalable and improves performance.
So, curious, when do you actually use triggers for your stuff? Also, do you agree that not allowing an "unknown" to occur in the database is better done by a "NOT NULL" constraint on a table or do you enforce that business logic only in the front end?
I do agree that doing business logic in the right environment will definitely add to performance, scalability, and maintainability but I'd never say that business logic belongs (only) in the application even if there were no notable exceptions.
When I use a trigger, it is to enforce some odd constraint that must be enforced under certain conditions or only at runtime, that is only suited to DB application instead of app application . I use constraints for whether a field can be null, default values, etc. Those are design elements that work well, My goal is to keep DB calls quick, short, and simple. When necessary,, I can control the transaction via the application, but only when necessary. I did not say business logic cannot be in the database, but that when you look at the any given use case for that, it is quite difficult from a value engineering perspective to justify it.
An interesting POV. I have to say I take the completely opposite view. SPs are a wonderful place to put business logic in addition to simple constraints, especially when you need transactions.
I certainly do agree that the server use should be minimized but in many cases keeping the logic inside SPs does exactly that, especially if the logic involves a lot of data from different tables. Security is also better since an SP is a black box with only known inputs and outputs. Having to make several calls to the DB to collect information required to implement complex logic in the app would seem to be counter productive. Sure, each call may involve only one small DB operation, but how many calls does a single business logic rule require? That also requires either A) direct table access or B) a loosening of the principle of least privilege, neither of which is (IMO) a good idea.
Also, there's the convenience factor. When BL is in SPs it's a lot easier to modify it without disturbing the application. Also, putting BL in the DB side means a (different) application can't freely ignore the business rules.