There are indeed a handful of classes-- some in d_ctl.c-- (and probably externals, too) which take signal input and output some message like "bang" on block boundaries (by using a clock callback). Still, there's no "control rate"-- "threshold~" doesn't output data every block. It outputs data only when the threshold value is exceeded, quantized to block boundaries.

At least in my fork (Purr Data), the control outlets are visually distinct from signal outlets. So upon instantiating [threshold~] you can immediately see that it doesn't output signal data.

For example, when you make a signal connection (thick wires) in Pd you immediately get a signal "flowing" through that part of the diagram. It is similar to making a connection between two modules on a Buchla synthesizer. That is very useful for prototyping because you immediately get aural feedback as you connect things together. (It's also efficient because you are doing computation on vectors of data.)

That doesn't happen with control objects in Pd. When you make a control connection (thin wires) no function gets called until you somehow trigger an event that causes the object to output some data. That is very useful for prototyping because you can make arbitrary turing-complete scripts full of branches of heterogeneous data which only get computed sporadically.

I guess someone could write a library cloning the core DSP objects and have them do "control rate" computations. That is, have them do a single computation per block, and copy that value for the remaining samples of the block. I imagine no one has done that for the same reason Pd only has a single numeric (float) type-- it's good enough as is.