From my experience, if you find a way that works, go with it until it quits working. Then worry about fixing it. It's not a bad thing to want to do things the "right" way, just be careful not to create too much work for yourself.
I agree with Fortinbra, to a certain extent. From a pragmatic standpoint, go with what you know best, are more comfortable with, and can deliver in a timely fashion.
That being said, I try like crazy to avoid UDFs. I use them when the SQL for a single statement gets too darn ugly, and when I have to return one scalar value per affected column per row, based on data from the row. You can use stored procedures for that sort of thing too, so there's really no advantage that I have seen to using one over the other.
For application development, I use stored procs for just about everything else, including simple selects. It helps secure the data and minimizes the temptation on evil developers to use dynamic SQL. ;-)
For DBA work, I use lots of scripts and the GUI (because I'm lazy).
My company uses a stored procedure to create dynamic queries, inserts and updates. I keep trying to push them to do a schema update, optimize it a bit. right now it looks horrendously like an Oracle fast port. Which is exactly what it is.