We still worry about costs, forecasting, latency, monitoring, availability, access controls, auditing, and resource utilization. So, I don't think "opsless" is applicable in the least.
But we don't worry about servers or nodes. We don't worry about zones or regions (we do worry about legal jurisdictions, but that's non-technical concern).
When I go to a Jimmy John's, I'm never served by Jimmy John. So what?
It's great marketing, albeit not what every person imagines, when encountering the term.
* edit was working on vault and for some reason typed that word instead of lambda
EDIT: markup (not a frequent poster here :) )
Some will say that PaaS did have knobs for amount of servers/instances/dynos/whatever but that's a minor detail and the innovation is called autoscaling. No need for an entirely new buzzword. But naming is both hard and exciting so we have "serverless".
Whereas serverless/Lambda/container service can take the billed cpu to zero when you deem fit. There are still cpus managing and administering, but you have the option to take your utilization that you get billed for to zero, where in the PaaS that I've been sold to, I didn't have that option. YMMV, of course.
Those who don't "get" cloud likely haven't seen one big use case where the costs of cloud services are pretty immaterial: very large organizations with human-dominated change processes. The win here with cloud is the policies and contracts are embedded into the API and access configurations. The speed-up isn't from elastic services, it is eliminating the layers of humans standing between you and the service you want delivered.
If you work in such an organization where you send in a change ticket with the exact Unix commands you want run, and it takes a week for the sysadmins to get around to processing the ticket, the cloud seems lightning-fast by comparison. Then all the scaffolding to set up CI/CD, CMDB, configuration management, secrets store, elastic services, etc. either on-prem or in the cloud doesn't seem nearly so tedious any longer.
E.g. server hosting, container hosting, database hosting, app hosting, function hosting, web hosting.
Considering that 'serverless' actually needs a more experienced and expensive ops team, no, it really wouldn't.
From my experiences the opposite is the case: The amount of time spent on operating a serverless architecture is much smaller than having to care about the underlying servers as well.
A pretty good example are all the nasty OS-related security vulnerabilities. Instead of patching hundreds of servers, like in the old days, with serverless applications you don't need to do anything. Even better: Your provider (at least if it's one of the major ones) has probably already patched these vulnerabilities, before they get published.
A good serverless platform lets you focus on those issues instead of OS patches and hardware upgrades.
"Auto-scaled-CGI-as-a-service"