I think the implication is there, are multiple "instances" of the scheduler. It might because the app is being served out of multiple datacenters, or even just multiple instances within the same datacenter (one per rack?).
These scheduler instances dont know what app instances are already being run by *other* schedulers. They are self contained.
So if a request happens to hit an scheduler instance, that has no app instances running, there is nothing to do but wait for a appstartup. Even though there are maybe other app instances sitting idle.
Google probably does some complicated routing to try to always route a incoming request to a scheduler that is likly to have a instance for your app. Maybe some sort of consistent hashing. But sometimes, that jsut will not work out. maybe the scheduler lost connectivity with the router. Because the router will also be a distributed service - probably running right at the edge of Google network. Maybe the instance scheduler is being decommissioned - taken out of service. For a while it will still have a app instances running, but they will be inaccessible. At scale - particully distributed - nothing happens 'instantly' and consistently, eventual consistency rules.
In general AppEngine is engineered for scale, tremendous scale. An app with many app instances running (so each scheduler should always have running app instances) - will not notice these occasional blips. Whereas with a mostly idle application, the relative chance of getting a routing 'misdirection' is much increased.
Now of course Google could work more to lower the chance of it happening. eg having the routing frontends and the schedulers being more tightly coupled, but the overhead of this, is likly not worth it. It would vastly complicate the overall system, both in code, and bandwidth, that it would probably slow down all requests somewhat.
(Note, I dont know this is how Google implements appengine, but it seems likely)