I read about Simonyi and why he prefixed stuff and Hungarian notation is a misinterpretation of his work.

The prefix was to denote purpose but has been misinterpretted as denoting type.

I've also seen the argument about whether or not to put business logic in the DB layer come around full circle and no doubt it will do a few more loops over the next decade.

I am sceptical about the argument that putting the SQL in the app makes it more readable and maintainable. I could understand it if the tools available or the favoured tool was not particularly good at dealing with database objects. To me stored procedures are conceptually the same as refactoring out code down into smaller and smaller methods. Yes it becomes a pain in the arse to drill down deeper and deeper into the code to find its like a Russian doll but ultimately you end up with a single simple method call.

I think where there is an unhealthy separation of roles between application developers and SQL developers then you get friction points and misunderstandings. I was an application developer long before I dealt with SQL Server so when I started out the idea that I could encapsulate a query to GetCustomerByID into a single stored proc was like manna from heaven!

From a production DBA perspective I think a large part of the worry is that there will be a 3am phone call complaining about a DB problem and all you can do is point to a particular query but have no way of fixing or mitigating the problem. Word gets around that "its a DB problem" and you end up whipping boy. I've been on the wrong side of a blamestorming session and no facts were allowed to contradict the "its a DB problem". It was actually an unclosed transaction in a loop that instantiated command objects to execute in RBAR fashion.