I support adding a Timer class.  

Have you considered supporting the existing ns-2 API?:

        void sched(double delay);       // cannot be pending
        void resched(double delay);     // may or may not be pending
                                        // if you don't know the pending status
                                        // call resched()
        void cancel();                  // must be pending
        inline void force_cancel() {    // cancel!
                if (status_ == TIMER_PENDING) {
                        _cancel();
                        status_ = TIMER_IDLE;
                }        }
        enum TimerStatus { TIMER_IDLE, TIMER_PENDING, TIMER_HANDLING };
        int status() { return status_; };

The main difference is that an error is raised if you try to cancel() a
non-pending timer or schedule an already pending timer.  Having slightly
different semantics like that may catch some programming errors.

Actually my Timer was inspired by the ns-2 one, but I could not understand how
differentiating between sched and resched has any use.  If I was programming
with these timers I would always call resched to make sure it always works. 
Slightly different semantics just adds a bit of extra complexity to the API and
I'm not sure there is any again.

Nor why status() is any use; perhaps a IsRunning () method could help, but
other than that...

In ns-2 resched is used about 250 times, vs about 90 times for sched.  And in
any case I would argue that in this code:

NS_ASSERT (!timer.IsRunning ());
timer.Schedule ();

the precondition that the timer must not be running is easier to read than when
it is hidden in this code:

timer.Schedule ();

I made some API changes to make the class a bit more useful:
http://code.nsnam.org/gjc/ns-3-olsr/rev/748960451370

code branch has moved; relevant URL is now:
http://code.nsnam.org/gjc/old/ns-3-olsr/log?rev=timer

Obsoleted.