So, here's why you want systemd time events:
systemd timer events allow you to make use of the same execution parameters of any other systemd service, which means you can limit resources, change users/group ids, set nice values, oom score, IO scheduling class, IO scheduling priority, CPU scheduling policy, CPU scheduling priority, CPU affinity, umask, timer slack, capabilities, secure bits, control group memberships, control group attributes, network access, private /tmp, namespaces, system call filters, ... individually for each job.
As the services started by a timer unit is a normal service it can pull in arbitrary dependencies on activation. That means you can actually sanely write cron jobs that depend on what they need.
As timer events are just one way to activate a unit you can actually combine that, so that you can spawn a service triggered by different events. Think: there's now a sane way to invoke something on the command line + at boot + if hw is plugged in + on a time event or if the user starts it explicitly, and the service will be executed in the exact same environment.
As timer events are just like any other units you now have a sane way to enable and disable them: "systemctl enable" and "systemctl disable".
All output of systemd timer events ends up in the logs, and is indexed by the event.
systemd can schedule time events both on monotonic times (think: run something every so and so often regardless of timzones, DST, the user mucking with the clock, broken clock, clock battery gone...) and on calendar times.
systemd calendar time events are more fine grained than cron (1s precision)
systemd calendar time events are more expressive (you can have repetitive and non-repetitive events, you can match on years, and you can actually match a week day at the same time as a day of month). And also I'd claim they are easier to write and especially read than cron time events. (See the lower part of http://www.freedesktop.org/software/...temd.time.html
 for details)
the systemd timer scheduling is a bit more energy efficient as systemd wakes up the CPU only when the timer elapsed, and not repeatedly as cron does
In cron if you wanted to avoid that slow running services are spawned multiple times you had to invent your own locking in the job. In systemd that's implicit, as the trigger is just a trigger, and the service will never be started at once.
You can even express timer events that are scheduled based on the finish time of the previous execution, i.e. for example to say that there should always be 1h between executions, even if each of them takes 2h.
You can combine timer events easily. e.g. "5 min after bootup + every day at 6am".
You now have a nice way to stop/kill a cronjob (and all its children), and only that one cron job, with "systemctl stop" and "systemctl start"
You now have a nice way how you can figure out to which cronjob a process belongs to, "ps xawf -eo pid,user,cgroup,args".
External programs can query all details about timers and the jobs. Execution status, when they ran the last time, and so on. There's a pretty complete, documented API for that exposed on the bus.
We now track failed cron jobs nicely, and just typing "systemctl show" will show them to you.
You now can establish cronjobs only in certain system states. For example, you can queue a cronjob only if the network is up, or suchlike. Think of cronjobs that are pulled in by the equivalent of classic sysv runlevels, only.
And yeah, the scheme makes timer events uniform with other triggers, so it's simpler to understand for newcomers...
The interesting bit about all of this is that the code necessary for implementing all of this is pretty short, since all the complex bits (spawning/supervising a process in a precisely defined execution environment, pulling in deps...) is just the stuff we do anyway for normal services. The only additions for supporting timer events, was basically a parser for the timer expression language and a bit of code to tell the kernel to actually wake up systemd when the timer triggers.
So, yeah, the code we had to write was small, the benefits gained throught it are substantial, so we did it.
I figure embedded people will start making use of all of this first.