Some context for thisi question: it is not about development time over the entire iteration of development, but just the stage of deploying changes from dev to prod environment. LINQ here really means LINQ, ORM, or C# where T-SQL would otherwise be used. And here stored procs is just a general term that encompasses database objects which include stored procs, functions, and views. Question was just phrased as LINQ, stored procs since the two are commonly compared in questions. To narrow the scope of the discussion we can assume web applications. Now finally the question is,What are the trade-offs in the cost of deployment (from dev to prod) between the two approaches? Some say it's easier to rollback Db schema changes than rollback changes across C# files in a solution. Others say it's easier to version or source control C# code than Db schema objects. If you make changes to LINQ queries, you'll most likely need to recompile the app to push the changes to prod. If you make changes to database schema, then that may require having a T-SQL script run in order to sync the changes to prod.As with many decisions with programming, the chosen solution may be context-sensitive. e.g. for data structures some situations may call for a hash map, and for others, it may be best to use a stack. Each has its own advantages/disadvantages. 
cost trade-offs for deploying changes to prod, stored procs vs. LINQ 
version control;database;development process