I have read many people opinions both from Unity forum and another forum. It seems the conclusion is that OnGUI is slow and can impact the performance. Well, the developers should be the one who know best about this issue. Why they don't improve it is really puzzling.
So basically, should I avoid OnGUI for iphone/android development at all costs? How much OnGUI elements (aka loop) which start to cause the performance hit? And what's the alternative way to draw GUI besides using spritemanager from Brady (I'm currently adapt a free spritemanager script to draw some buttons but it's really not convenient)?
Yes, you should probably avoid it for the time being, but it's dependent on how heavy the rest of your game is, and what devices you're targeting. It's potentially just fine for use with menus.
They are improving it. The progress was impeded by the not knowing whether Apple would enforce use of C++ for Unity scripting, last year.
There is no "convenient" alternative. For the time being, you just emulate the subset of UnityGUI that you need. That is, texture some quads, use efficient shaders, and use Text Meshes where you need dynamic text. I make heavy use of Rect.Contains, for Input.
Avoid it if you can, but for start/pause menus and a small HUD it's fine. The most important thing is that you really understand how the GUI system works, and that you make the OnGUI function do as little as possible.
This function is called twice every frame and once every event (!). Use it only for the actual drawing of the gui, but do all calculations somewhere else. If you'd make a health bar, the function that keeps track of your health would be inside the Update function for instance, and the OnGUI would just plug in the result. Or even better: the OnGUI would only be called if the result is different.