Looks like we missed some of the doc comments. Hmm.
A little history on the issue. In 2.x, timers ran at most once per frame, and the activation times were snapped to the frames. This meant that you couldn't schedule something to run more often than the frame rate, and timers with a frequency close to the frame rate (which is not constant) would have problems as well. Timers were not very accurate at all, and this was a major problem when trying to add integrated physics. It was also expensive to have many timers waiting since every timer was checked every frame. None of this was documented outside of the code itself though.
In 3.x, timers are deterministic, and run based on real time so the timers actually run at the correct rate regardless of the frame rate. In 2.x when you asked for a timer with a delta of 0, you were really just passing it a number that was guaranteed to be shorter than any frame. That was then limited to running once per frame. That trick doesn't work anymore since it respects the rate you assign instead of limiting it.
Adding back custom selectors that run on the update cycle is probably not going to happen since there are also fixed updates now too. The API and implementation would turn into a mess pretty quickly. I have been thinking about a way to specify to run a CCTimer object on the update cycle though. Similar to how Unity does it with coroutines perhaps. That would be a lot simpler in both regards. There aren't any plans beyond the thought experiment though.
Lastly, consider that the old 2.x scheduler checked every timer every frame to see if it should be called. That's the same as what you suggested at the end of your post, but the condition is flipped. Depending on your usage, it's not really any more or less wasteful in that regard.