My own hypothesis is that the teams building these FaaSes wanted to choose a runtime that has a good story for internal multitenant partitionability, so that they didn't have to either just-in-time spawn, or prefork, a new (containerized) copy of the runtime for each user, with all the overhead that implies. Node.js is such an internally-partitionable runtime. (So is Lua†, but like the parent says, Node.js is bigger and more people want it.)

For a visible-to-the-public-eye example of what I mean, look at how CouchDB uses Node.js for its view functions: the CouchDB daemon process spawn an unprivileged Node.js slave process, which uses Node's ability to drop or virtualize syscall-making APIs, along with Node "VM"s (https://nodejs.org/api/vm.html) —essentially the same kind of isolation as you get from distinct-origin browser tabs—to allow for the execution of arbitrary Javascript by multiple tenants. That's not too far off from a FaaS already. It's a good model to copy and extend.

I'm betting AWS Lambda, and Twilio's offering as well, are mostly built around such a model. Mind you, Lambda now also offers a "prefork" container-based stack for function execution, but it didn't at first, and for good reason: it's harder to build, harder to operate, and has much higher overhead than a cluster of regular processes with internal sandboxing. This is much the same reason that Heroku started with their Alpine stack—an cluster of internally-partitioned Ruby processes, and boy was that a feat—before building their container service.

---

† Given that you could pretty easily multitenant-sandbox Lua evaluation... it'd be quite easy to extend OpenResty (https://openresty.org/) into being a FaaS, wouldn't it? Anyone hacking on this?