In the modern age this isn't really a common approach anymore. There was a time that putting business logic in stored procedures was a common thing to do early in web programming because the alternatives where few and often difficult to use. Today I would recommend against it.
I would have to say in 2012 there is nothing about business logic in stored procedures that could be justified as somehow a choice having beat out other approaches after having weighed the pro's and cons's. Any PRO points would be academic at best.
It's not linq code. The future of TSQL is compiled linq, mine as well start to learn it.
Compiled code is more stable and easier to work with. If I'm debugging something there is so much information available if I used C# or Java.
Stored procedures are likely to end up with too many responsibilities, it's a best practice to try to keep your responsibilities to 1.
Lack of separation of responsibilities will lead to an application that just gets harder and harder to work on and less and less stable as it's core classes just get bigger and bigger.
If you like Microsoft Asp.Net MVC combined with Entity Framework Code First will allow you to rapidly build any application and you won't need any stored procedures.