Pure CGI applications (before the mod_x / long-running workers strategy took over) are "stateless" / "function as a service" insofar as the application's internal state can only live for one request lifecycle. However, they generally ran with the external state (ex. local filesystem) preserved between requests, so the approach was still often a bit different than it is for modern FaaS applications, where state can only live off-server (ex. in a remote datastore or another service).
If you take a CGI based implementation and constrained it to use only external managed services, and you use Lambda to serve it up, you won't need to manage servers explicitly.
The real serverless apps are pure clients that use 3rd party services for everything - i.e. the developer doesn't write any backend code that runs on their own infra.
Is something like mod_php what you'd consider a CGI application? I always think of CGIs from before the day when webservers made it easy to integrate a runtime. For me, CGIs were usually binary executables that the webserver handed data to. I always thought it was about the data exchange, instead of about application state, because http requests are by default generically stateless.
To me it's about the application lifecycle, so no, I wouldn't consider mod_php CGI (which is why I specifically called it out in my parent comment).
CGI does the same thing Lambda does: it binds the application lifecycle to the request lifecycle. HTTP requests to an application server that runs across multiple requests are not stateless, they're inherently bound to the server's internal process state. If the server is well-written this shouldn't matter, but the entire reason an application has to be refactored at all to become a Lambda is that this is not usually the case. Most modern application-server style web apps are loaded with mutable global state that lives through many requests - from thread / connection pools to global caches to updatable configuration stores to even dynamically loaded code/modules.
