But before I get to these there is something to be said for implementing abstaction layers by providing interfaces and hiding implementations behind interfaces. You can thing of stored procedures and views in a database as just an interface layer between application components. When you do that, it becomes clear that stored procs and views are just another tool in the arsenal of a well rounded developer.
Back to why you might use views/stored procs. Let's start with complex applications environments. When you're dealing with multiple applications - some legacy, some new, written across a set of technologies - COM, JAVA,
In database land you must have consistent, repeatable, up to date data. By housing business logic in the database, you expose to users standard views and procedures that ensure that consistency is maintained between inserts, updates, and deletes. Often these same mechanisms are used to prevent too much access to data. For example, you can preven value that are out of bounds based on expectations of business processes/relationships existing in your database.
Since databases house complex relationships (not uncommon to have to join across 5 tables to get the result you want), to think that the application layer should contain this complexity is to build a fragile system open to errors made by developers who do not fully understand the system, or if so make assumptions about what can/will change in future that are not property grounded.
Continuing, maintainability/business agility is increased with proper use of views/stored procs. If only code is used to access database information, it is much more difficult to update all the destops in your company when a database schema changes than it is to update the innards of a stored procedure with a well known interface. As such any logic that pertains specifically to reading/updating/deleting content from the database should at least be evaluated against a similar implementation that is in the database itself.
So with that you need to take C# in the database for what it is worth - it allows you more easily to define complex business logic (types, behaviors, interfaces) than the comparative T-SQL. As such it speeds development of database applications. It makes database maintenance easier by making the code more easily read/updated. It also lowers the bar to having good database logic by reducing the need for highly complex T-SQL. For these benefits there are drawbacks - portability, perf, etc.
As a professional developer/DBA it is up to you to be able to make these tradeoffs. It is not as simple as saying OO is the right way to go always - that's a purist's approach. Purists have issues in business environments where tradeoffs are required to achieve the expected objectives in the given amount of time and with the given set of resources.