Question: I have a C# Application I am creating that stores all data in SQL Server. 

Sometimes it's easier for me to make data changes programmatically and sometimes it's easier to have stored procedures and functions in the SQL Server database and call them.

I am rather new to programming and I don't know what the subtle advantages and/or disadvantages of each method are.

I figure I should probably be doing things one way or the other instead of using several methods. 

My code is starting to look like a random collection of thoughts all just shoved into one spot. No offense to Joel Spolsky. I love his books.

This is a solo project, so I can refactor any amount of code I want to make it better. All options are on the table.

Thanks,

J3r3myK

Answer: 
Two points that haven't been covered yet:

SProcs can be placed in a schema, and impersonate a different schema. This means that you can lock down the database access and give users permissions ONLY to execute your SProcs, not to select update etc, which is a very nice security bonus.

Secondly, the sproc can be SIGNIFICANTLY faster depending on what operations your doing. If your constrained by network IO and your able to perform set operations on your data, doing so in a single stored procedure instead of doing a fetch of the ENTIRE dataset, processing it, then transmitting the change will give you a nice speed increase.

Same goes for transactions, if you need to perform operations serially (i.e change a value in two tables at once which involves some logic) then you will need to hold a transaction for the time it takes for you to compute the value and transmit back in two SQL queries, whereas the stored procedure can do it in a single procedure.
I would recommend following one convention or the other (either have your SQL code as strings in your classes or use stored procedures). There are countless debates about this, but there really isn't any important reasons to choose one or the other.