I'm not sure splitting process and I/O scheduling is really worth it, as they're often deeply interconnected anyway. (E.g., if a process is waiting on I/O, it can't be scheduled to run). Also, network scheduling is more normally called QoS, rate limiting, or traffic shaping, and is configured differently than disk I/O scheduling, so I wouldn't include it in I/O scheduling. I'd suggest keeping scheduling the refer to process and I/O scheduling, though would not object to splitting that to process-scheduling and either disk-scheduling or io-scheduling.
Job scheduling is, I think, not normally used to refer to cron-style "run this at 01:03 every Sunday"; it's closer to what
batch does. Though would often be used across a cluster. So I wouldn't use that.
Task Scheduler is the name of a Windows component. It's also quite close to multitasking, which is what process (and I/O) scheduling does. Further, "task" isn't normal Unix terminology. So I wouldn't suggest that.
The cron manpage describes it as a "daemon to execute scheduled commands". So I'd suggest command-scheduling.