Here's something I'd like to add to this discussion.

"The goal is to create routines with internal integrity (strong cohesion) and small, direct, visible, and flexible relations to other routines (loose coupling)." -- Steve McConnell

I think we can (or should) agree that it is poor design to embed printer control codes in an application and it is better design to create a separation layer between the app and the printer. That means a 3 layer minimum.

This constant raging debate over SPs or not is pointless simply because an all SP or a No-SP approach is a 2 layer design. If you disagree - T-SQL is a separation layer between the data and the app, that is from a limited perspective. A printer is a separation layer between the app and the paper, but we still consider it a single layer. Likewise we should consider a database backend as a single layer.

The application is the interface between the user and the database - but that also is not the correct perspective. The application is the user in the same way the printer is the paper.

There is a missing "layer" in all of these discussions. With this layer application programmers and DBAs can do whatever they need to do. This missing layer makes for a single place for the implementation of business logic.

Things that are best done as dynamic SQL can be done there and things that are best done as SPs can be called from there making for the BEST possible results for the people this industry serves - the business and the users - not the programmers nor the DBAs.