I was excited when i read that cycles is making its way into rhino - but i think in its current state it is unfortunately not very useful for several reasons:
Response time / interactivity:
The main purpose of cycles should be an interactive preview.
In the current state viewport orbiting, object transforms etc. update way to slow, the fallback shading is not working right either.
This happens with cuda and cpu. Undersampling is not used at all - why?
Rhino was never famous for its default settings, the initial viewport shading still looks like a bad dream from 2005, and with cycles it is no different.
It took me 10 clicks in 2-3 different panels just to get a black background, no lights and no ground plane.
Where do the sampling defaults come from? 1000 image samples etc. - blender has quite different defaults, and they are more reasonable.
This is a deal breaker. Without some kind of color or tone-mapping (cycles has filmic now), and no way to render 32bit images, it is pretty much useless in any kind of production scenario.
Plaster, Pastic, Gem, Glass,… i like to think that rhino is a professional software and that it can be expected from its users to get accustomed to words like ‘lambert’ or glossy bsdf. Why have a precise language when geometry is concerned, and kindergarten expressions once it leaves the realm of modelling?
Bottom line - in its current state cycles is not more than a nice gimmick that ships with rhino. I was hoping to use it somewhere in my pipeline, and also with students, but it is not ready yet. I don’t know if mcneel plans to improve it during the v6 cycle, but it would be unfortunate to be stuck another couple of years with the rhino renderer which has probably 10 users worldwide ; )
All other serious options are payed plugins, and especially in schools that poses a problem.