Yes, the documentation in question is incorrect. You can prove that the Limits class does not conform to what is written therein fairly easily:
public class Demo implements Queueable
{
public void execute(QueueableContext context)
{
system.assertEquals(1, Limits.getLimitQueueableJobs());
}
@future
public static void doStuff()
{
system.assertEquals(1, Limits.getLimitQueueableJobs());
}
}
Proving it for batches is a fairly straightforward alteration of the above.
Some pieces of the documentation, however, do touch on this point in a way that properly explains the governor limits involved. They are somewhat lacking in clarity, but you can only execute one job from within a job. Here's one such example:
If you need to run a job after some other processing is done first by another job, you can chain queueable jobs. To chain a job to another job, submit the second job from the execute() method of your queueable class. You can add only one job from an executing job, which means that only one child job can exist for each parent job. For example, if you have a second class called SecondJob that implements the Queueable interface, you can add this class to the queue in the execute() method as follows:
public class AsyncExecutionExample implements Queueable {
public void execute(QueueableContext context) {
// Your processing logic here
// Chain this job to next job by submitting the next job
System.enqueueJob(new SecondJob());
}
}
Also from the same document:
When chaining jobs, you can add only one job from an executing job with System.enqueueJob, which means that only one child job can exist for each parent queueable job. Starting multiple child jobs from the same queueable job isn’t supported.
Best Answer
See Queueable Apex (emphasis mine):