Pondering LSL timers

I've often been curious as to the design decision behind the way that llSetTimerEvent() and timer() work. I look at them and think "that's really not how I would have done it". While I imagine there's good (or at least historical) reasons as to why it works as it does, I find myself wondering why it doesn't work more akin to listens, like this:

integer llTimer( float sec );
llTimerRemove( integer handle );
timer( integer handle ) {;}

The idea being that you create a timer event and store its handle, detect and act on it in the timer event using its handle, and remove it with its handle. For example:

The main issue I can see with this is that you could very easily end up with multiple timer events all firing at once (in the above example you essentially get the need to fire a timer event twice in one go every 20 seconds and three times in one go after the first 60 seconds). I wonder if that was/is the concern? (it's worth noting that multiple listens result in a single fired event if they overlap so this is obviously where the listen handle analogy breaks down). There's also the concern regarding too many timers but that'd be easily solved by simply having a reasonable limit (again, much like listens).

Of course, there are any number of "workarounds" that let you have multiple timed events happen with a single timer, and the lack of something like the above has never been a great hindrance, but I can't help but feel that, every time I do work around this, I'm doing something less elegant than it should be.