I was a developer long before I became a DBA. I went on the two original SQL 6.5 courses. I realised that the ability to write stored procedures made my life as a developer easier.
IMPORTANT POINT ONE: Developers have to be able to write stored procedures
I mean they need sufficient access to write the stored procs for themselves, they need to make mistakes for themselves they need help to learn, they need mentoring such as they would get in their normal role from a senior developer.
They won't be fans of stored procs if it is something that only the priesthood of DBAs, data team etc get to write.
IMPORTANT POINT TWO: Neither developers or Data people can afford to be a one trick pony, no matter how good that trick might be.
My stuff has to work well with other peoples stuff and vice verse. Producing the ultimate database is not the goal, producing the ultimate code is not the goal. Producing the overall system that fulfils the business need and is at worst cost neutral is the goal.
Learning a bit about each others world will help each be more sympathetic to the other.
IMPORTANT POINT THREE: Culture comes from the top and culture trumps strategy
Behaviour descends to the lowest level that management will tolerate. If the technical leaders have strong biases then those biases and behaviours will permeate downwards. If the boss believes that one discipline is lesser than another then if they are not careful to hide that bias it will spread through their reports downwards and will last long after they have left.
If the boss comes from a "Stored Procs are bad" background then you have a problem.
The legacy of poor or absent leadership lasts far longer than that leadership.
IMPORTANT POINT FOUR: Business logic is too vague a term to be useful
What happens if a business function is best expressed as a set based operation? Do you insist in doing it in some non-database tier of the code?
What happens if a business function is best expressed as complex iterative logic? Do you insist in embedding it in a stored procedure?
Can we not have some common sense rather than perpetuating the drivel about business logic? The genius of AND vs the tyranny of OR! Again, if developers are allowed to, are comfortable with and encouraged to write stored procs then it becomes a case of saying this function is best off expressed as set based logic, this function is better off done in whatever coding language is appropriate.
IMPORTANT POINT FIVE: Understand the difference between storage, presentation and interaction
Just because developers want to pass around data as JSON object doesn't mean that it has to be stored as JSON objects. Just because data might be stored in a relational form does not mean that it has to be presented in tabular format.
IMPORTANT POINT SIX: Sometimes stored procs are NOT the answer!
In a data warehouse/mart they are useful for data pipelines but for end users of the data mart probably not so much.
IMPORTANT POINT SEVEN: Sometimes stored procs ARE the answer
I think of them as either public methods for objects hiding private members or as encapsulations. This can be incredibly important for OLTP systems. They can abstract the complexity away from the app. Again, the procs have to be visible and writable by the developers.