All over the internet you will see examples of use where a lot of people are basically creating scripts to manage countless amounts of interpolation states and a lot of logic embedded into the actual Update of the behavior class. Cameras, player movement and event monitoring. Avoid it! Just flat out try to stop it. Use events with animation curves, states and animators to get around that. You do not need to setup a manual interpolation for every value that transitions smoothly over time. There are Animation Curves for that and Clips with events that can be sampled by the native engine and will perform a lot better and call your events handlers when they reach a particular point you have authored.
Your game should be littered with trigger volumes that call your scripts so that you can set states, and from those states create the interpolation objects that can also trigger events and state changes in animations. If you are smart about this, you can setup a very efficient chain of events that is mostly handled by the underlying mechanics rather than your buggy C# code.
Most of the examples I have seen online are not really tailored towards programmers or engineers that have been solving such problems for years. It is more for the novice that need to get up to speed as soon as possible.
Using these event features correctly will also allow you to use a lot richer content and see your games run on smaller platforms because they are doing a LOT less work.
For the more experienced programmers, trying to use Unity in a lot more content driven way will also allow you to use native development tools for development and debugging since you can always just forward the state and event changes to native libraries you have created. You could write those native libraries in C# also, meaning that if you are working on windows, you can have mono call into your native dll that is written in C# also but a separate library that you can easily debug with Visual Studio Express. Decoupling for the sake of tool support and performance.
Unity calls these sort of native libraries plug-ins. Where you can also do some custom rendering if you would like to. But for security reasons, they are disabled for the web-player, so a game that is dependent on native plug-ins would need to be downloaded to your hard drive to test.
Also be aware that the performance of C# is drastically different on smaller devices than on the PC you are developing. There are certain features you should avoid, such as using properties and not caching your look ups into deeply nested objects.
I like Unity, but you have a lot of people contributing bad examples on how to use it properly.
V 