That's basically true. It's not _impossible_ to optimize them
(inlining "tick" functions, etc), but it would be a completely
different problem to tackle. A pretty interesting one however!

That would be a interesting approach indeed. We would need to be careful and make sure we could still consider the internal state of individual UGens in such a graph, as we may want to change the UGen graph with as few glitches as possible.

Sorry for the confusion. I meant opcode as it is used in talking
about compilers. The word just refers to "operation codes", i.e.,
codes that represent machine instructions. In ChucK, its VM opcodes
are actually instances of the Chuck_Instr class. Not the same as
CSound's opcodes. (Though, shamefully, I don't actually know CSound
very well.)

Ah, I see. IMHO CSound is nice as it's so old and established that many very worthwhile articles have been written with it in mind. It can pay off to be able to read it to be able to understand those articles. To me personally it does look a lot like a language that's decades old if we compare it to ChucK; I think you'll be fine without it.