Unfortunately, there isn't really a "missing" K2 manual. There is the K2 blackpearl Developer Reference which you should be able to download from the portal which is probably where some of these answers will ultimately appear (but at this point, it doesn't answer any of them). Also, to provide a shameless plug, toward the end of the year the book Professional K2 blackpearl should be released and that will address many issues in greater depth.
You ask some pretty important questions.
1) SmartObject lifecylce management: This is a tricky and confusing topic. You really need to understand exactly how SmartObject versioning works. I have a blog entry which discusses versioning around SmartObjects in some detail. Basically, the important thing to understand is that all existing processes will continue to use the version of the SmartObject which existed at the time you published your workflow. It is up to your SmartObject Service to gracefully handle different versions of a SmartObject requesting data.
2) Repeating Rules: I have a few different approaches for you here. Typically, if you need to use the same values over and over again, the best approach is to store them in a process level data field. Alternately, you can copy line rules. Just select the line, Ctrl+C, click on the activity you need the line for, Ctrl+V. The reason copying the line rules is not a great solution are for the reason you've already discovered. If you ever need to change the way the value is calculated, you have to change it individually for every line.
3) See 2 for a better way as far as not needing to access the SO in every line rule. There isn't currently any kind of automatic renaming with SOs or SO methods, etc. Definitely something I hope they fix in a future release.
4) The pros of writing code are that you have a lot more flexibility to make K2 work exactly like you want it to. Indeed, many times, you have to write code to get K2 to do what you need it to. The cons to writing straight code is that you lose the ability to use the GUI for that piece of functionality and it becomes far less transparent what K2 is doing at each step, but as long as you use good naming conventions you can mitigate that somewhat. I have a blog entry on some additional reasons writing code is good in the context of team development.
Hope that helps,
Colin
K2 Insider
K2 Blog:
K2 Thought