Well, if you're deploying on an architecture with very specialized machinery, even up to JSON parsing and REST API handling, a scripting language isn't going to lose that much over a compiled one.
Maybe not python, but the future the article talks about is definitely one where "js everywhere" is a compelling approach.
In a way it harkens back to 80s 8-bit home micros. BASIC on these boxes is incredibly slow, but you can still easily do realtime sprite-based games because all it is doing is manipulating some magic memory locations that are mapped to dedicated video-drawing hardware. Instead of the software needing to blit every frame, all it needs to do is say "Sprite 3 moved left by 3 pixels" every frame. Instead of doing collision detection in software, you just read a magic memory location that tells you which sprites have collided since you last looked.
If you're writing the kind of game that is possible to do in C64 Basic, you don't actually gain much by writing it in assembler instead. What you get from writing in assembler is an expansion of the universe of possible games.
I agree scripting can be done top-level but it’d be shocking for it to be used for device management. These OS ideas are coming back to topics like microkernels, where you want to give applications part of the OS responsibility and hope they don’t crash you. I’d imagine that the scripting language can offload a lot of functions, but it’d just be glue on top of complicated accelerator mini-kernels, which themselves have native code programming e.g., some JSON state machine.
Maybe not python, but the future the article talks about is definitely one where "js everywhere" is a compelling approach.