We tend to not use Automic facilities that are not readily visible to our production support staff for scheduling of tasks. By convention all tasks are either in a Schedule object or objects that have been activated by a Schedule object. This also helps us in several areas such as ability to stop a Schedule and ability to just start Schedules after the rare "cold" start of the system. We do not need to concern ourselves with determining which other objects might need to be manually started.
We rarely use the Recurring execution option and to my knowledge never for production work. If this feature is used at all it is in the non-production Clients.
Our preferred method is to use Timed Events and have their Interval (! Process) perform the required object activation. The Events themselves are on the Schedule and normally have RunTime Supervision (MRT) that lets them run a bit less than 24 hours (for those that run continuously) and then are started again via the Schedule at the appropriate time the next day.
The Event's Interval logic, depending on requirements, reads either a Variable or a file using the appropriate PREP_PROCESS_VAR/FILE function. These contain the objects to activate and various information regarding their attributes such as Calendars, times of day or whatever else is needed.
We also use this technique for some File Events. They activate objects when there are matching files to process and in some cases stop themselves when there are no more files for some period of time or other criteria. Again, these events adhere to the above scheduling convention.