Cost is usually a good indicator, but it can be misleading -- especially if you only evaluate it on test servers with limited amounts of data. When you move your code into production where the number of rows may be much larger, you can have disasters.
The cost of the query is based on SQL Server's estimate of the number of rows. You can have a small table (or a small subset of a large table) where the cost for a certain operation is lower than another, but as the table grows (or the constraints of the query change), the reverse is true. This is one of the dangers of stored procedures because their execution plans get cached and may not get recompiled as your data changes. Don't get me wrong, I love stored procedures, and I never use inline code in my applications; I always call stored procedures.
RBAR can affect all four of the operations (select, insert, update, delete). One thing to always remember is: "RBAR bad, set-based good!"
Here are a few good articles on RBAR: