Serverless computing is exactly mainframe computing. And by exactly I mean exactly. You see when I was taking CS classes for my degree students bought something called "kilocoreseconds" (kCs) and they are exactly what they sound like, they are a unit measured in the combination of amount of RAM + the amount of compute per unit time your project consumed of the shared computing resource, the mainframe.
You also got a quota of storage with which to hold your projects before you "launched" them on the mainframe with the all powerful "run" command :-). For those of us who liked to explore, it was a very real possibility that you would have to buy more kCs to get through the semester. There was vendor lock in because Doh! you weren't writing operating system code, you were writing application code.
And once you make this connection, you can see all the problems that "serverless" has are all the exact same problems mainframes have for all of the same reasons.
Basically mainframes are "good" when you want to have a small team do all the compute resource management and you have many teams that will want fractional usage of that resource over time. You can developed a closed form solution to the question "what does this compute resource cost to operate per unit time" and you minimize all of the things that affect that cost. Everyone maintaining it are all in one building, all of the equipment is in one room, all of the maintenance is logged and verifiable, etc.
When do mainframes kind of suck? Well when you don't know whether or not you want to use them. Or when you have a different set of OS services you, and only you, need but burden every user of the mainframe.
It is hilarious when you think about it, imagine this giant homogeneous blob of compute, the mainframe, that people disliked because it was "far away" and they didn't have any control, so desktop computers became a thing so that everyone could have their "own" computer, but then networks got bigger so people started virtualizing their desktop compters so IT departments started building bigger and bigger computers to hold many VMs and then because people figured out they could scale by using someone else servers, they started putting their VMs in data centers with a bunch of other company VMs and the data center people optimized by making bigger and bigger data centers, until even the lower cost of a VM was really more than someone wanted to pay for just running a single program so the Data Center types built a layer over all of their machines and services to make it seem like one giant machine. Ending up, nearly exactly back where they started except that now one company owns a mainframe and dozens of companies use it to run their bits of code.
I literally laughed out loud when a low employee number senior engineer at Google proudly announced to the folks that Google was building this new concept of "Data center sized computers." This was like 12 years ago so I'm sure their vision has evolved but it never occurred to them (I checked) that maybe everything old was new again. But I still remember touring computer rooms that took up an entire floor of the building and were basically one computer.
When you get this, you can then go look at where mainframe computers are today. Look at how the IBM Z series can slice and dice itself into logical partitions or LPARs and dynamically become a compute nexus of just the right size for your application, in either bare metal or OS based versions. That is where "serverless" should be looking for inspiration. Modern "web 2" architectures still partition various services into clusters. So you have the EC2 cluster, the S3 cluster, the Elastic Search cluster, Etc. Make the atoms in your world the pivot point and dynamically allocate resource based on your exact needs. Then bill it out in the gigacorepackethours or some other unit of measurement that captures what fraction of the overall datacenter your application consumed and for how long.
Just don't bring back punched cards. They didn't really add value as far as I could tell.