Hearing this is one of those things that really bugs me.
And it's not actually about stored procedures, it's about the mindset that sits there.
I hear this sentiment in environments where there are multiple developers. Where they're using source control for all their application code. Because, you know, they want to make sure they have a history of changes, and they want to make sure two developers don't change the same piece of code, maybe they even want to automate builds, all those good things.
But checking out code and needing it to pass all those tests is a pain. So if there's some logic that can be put in a stored procedure, then that logic can be maintained outside the annoying rigmarole of source control. I guess this is appealing because developers are supposed to be creative types, and should fight against the repression, fight against 'the man', fight against control.
When I come across this mindset, I worry a lot.
I worry that code within stored procedures could be lost if multiple people decide to work on something at the same time.
I worry that code within stored procedures won't be part of a test regime, and could potentially be failing to consider edge cases.
I worry that the history of changes won't exist and people won't be able to roll back to a good version.
I worry that people are considering that this is a way around source control, as if source control is a bad thing that should be circumvented.
I just worry.
And this is just talking about code in stored procedures. Let alone database design, constraints, indexes, rows of static data (such as lookup codes), and so on. All of which contribute to a properly working application, but which many developers don't consider worthy of source control.
Luckily, there are good options available to change this behaviour. Red Gate's Source Control is tremendously useful, of course, and the inclusion of many Red Gate's DevOps tools within VS2017 would suggest that Microsoft wants developers to take this more seriously than ever.
For more on this kind of stuff, go read the other posts about this month's T-SQL Tuesday!