It is a perfectly logical name if you know what you are talking about and are familiar with the history of how these so-called serverless applications used to be developed.

Which is to say that back in the day, once CGI fell out of fashion, the applications became servers themselves. You would have a listening HTTP server right within the application, often reverse proxied through something like Apache or nginx, and that is how it would be exposed to the world. The downside of this model is that your application always needs to be resident in order to serve requests, and, from a scaling perspective, you need to predict ahead of time many server instances are needed to handle the request load. This often resulted in poor resource utilization.

Now with a return to back to the CGI-esq model, where you have managing servers call upon the application through a process-based execution flow, albeit no longer using CGI specifically, the application is no longer the server again. This allows systems to save on resources by killing off all instances of your application when no requests are happening, and, with respect to scalability, it gives the freedom to the system the ability to launch as many instances of your application as is required to handle the load when the requests start coming in.

Hence, with the end of the application being the server under the adoption of said process-based model, the application became serverless.

> I was dumbfounded by the term

The marketers have certainly tried to usurp the term for other purposes. It seems just about everything is trying to be called "serverless" nowadays. Perhaps that is the source of your dumbfoundary? Then again, if you know what you are talking about then you know when marketers are blowing smoke, so...