The main downside to scheduling 12 identical events is that if one gets lagged behind for some reason, the next one will run in less than five minutes. This may or may not be desirable. Particularly during maintenance, you may have all 12 jobs trying to execute immediately upon the system coming back from maintenance. Also, if you're running an organization that already has some 90'ish scheduled jobs already (including daily, weekly, and monthly jobs), using 12 slots is undesirable.
I personally prefer using "suicide scheduling" for a granularity of less than an hour, because it uses fewer resources and is still reliable. With suicide scheduling, your job purposefully does something, aborts itself, and schedules itself X minutes in the future with an hourly schedule fallback. This way, if it fails to reschedule because of blown governor limits or an unhandled exception, it'll run in an hour, otherwise it'll run in X minutes, and all you need is a single job.
Here's what it generally looks like:
public class SuicideScheduler implements Schedulable {
public void execute(SchedulableContext context) {
System.abortJob(context.getTriggerId());
System.schedule('SuicideScheduler', '0 '+DateTime.now().addMinutes(5).minute()+' */1 ? * *', this);
// Do your payload now
}
}
However, you could also avoid this problem entirely by just scheduling yourself hourly and using a Queuable/Batchable class that the scheduler kicks off:
public class QueuedScheduler implements Schedulable, Queueable {
public void execute(SchedulableContext context) {
System.enqueueJob(this);
}
public void execute(QueueableContext context) {
// Do your work here
//
// If you need to chain, then you can...
System.enqueueJob(this);
}
}