I hope that stuff is missing just temporarily - there is a lot of genius in the original GAE.
I suspect yes, but the last time I checked the Cloud IAP docs (for GAE standard's recent Python 3.7 launch) they didn't yet address the unique situation of second-generation App Engine standard environment runtimes.
It reminds me a lot of being back in the 80s, when you could write raw assembly that simply called BIOS interrupts to read and write from a disk (by logical disk number!), rather than there being this whole edifice of an OS kernel in between, mapping high-level conceits like logical disk requests to low-level SCSI/ATA/etc. wire protocol messages. That mapping was instead happening at a firmware level, such that the hardware (the CPU) could expose intrinsics that would look like any other ISA instruction, but which would turn around and use the firmware (the BIOS) to execute the instruction.
That BIOS-interrupt style really feels, to me, like how computers should be: rather than everything compiling down to RISC code that inevitably gets bogged down in kernel context switches as it attempts to express its intent through thousands of low-level system calls, why not have an ultra-high-level CISC ISA that can just express its intent to the hardware [and firmware] directly, with no impedance mismatch? All the "expansion" of intent to RISC would happen in ring 0, with no switching back and forth. (A good example of this kind of CISC-expression-of-intent: kernel packet filtering.)
Or, if you don't want to go that far: why not an abstract machine, like the JVM, with these hyper-CISC semantics? I know there's already one example of this approach in the way Erlang's BEAM VM implements its "send" instruction. In the expensive cases—when a module is not loaded in the local VM, or when you need to send the message to a remote node over the distribution protocol with a custom transport—the "send" op can bounce back down into calling other Erlang modules (essentially "firmware"!) to get its job done. I'd love an abstract machine that had that approach... but for everything.
---
† I say "felt a lot like", but from my understanding, this is how it actually was/is! GAE Standard Environment v1's interpreters are compiled as Portable Native Client [PNaCl] binaries, with extensions to the "ABI side" of the PPAPI for the specific services the Native Client VM host provided to its guest. The language runtimes then 1:1 expose these PNaCl instruction-set extensions as the functions of modules like ndb, taskqueue, etc.