-- The color cycling rules are complicated enough that it takes a fair amount
of logic to figure out which ambient, diffuse, specular and emissive color to
use at each vertex. At a minimum, that adds code bloat, which is a concern
for small memory (or small primary CPU cache) machines like macs and PCs.
You can precompute a lot of it, but it is important to keep the "for each
vertex v of a polygon, do: color(v)/normal(v)/vertex(v)" loops as efficient
as possible. Keeping track of cycle lengths (so you can do color(v%cycle))
adds four extra variables to these loops (plus if-tests if you want to
special-case the common case of one ambient/specular/emissive color and
multiple diffuse colors); add enough variables and everything no longer fits
in registers. All this probably doesn't matter on a PC, but we removed color
cycling from Inventor 2.1 because we were spending too much CPU time deciding
what OpenGL calls to make on Silicon Graphics' fastest machines.
-- It isn't useful very often. It is useful for chessboards. And I can see
how you could create some interesting looking, small landscapes using it.
But neither of those are very common.
There's an important philosophy mere-- features that cost something even when
they're not being used had better be useful enough to justify that cost.
All features cost at least some disk space (the browser executable will
become at least a little bit larger), and will probably also cost some memory
space (unless your operating system and compiler cooperate so that
seldom-used code is never put into memory-- true for Silicon Graphics'
systems, not true for others, I'd guess).
Color cycling is especially evil because it costs during rendering even if it
isn't being used, which is the most important place to be efficient.