I mean, really how much is Lambda more serverless than Heroku has been for years?
With Lambda, you're not getting a server. No OS setup, no ip-tables, no weird compile errors, and no 5am pagers. You're paying for code to run.
With Salesforce, you're not getting software. No installation, no packaging, no purchasing updates. You're paying for your team to centralize information.
While I despise Salesforce for many reasons, it was a game-changer in the way enterprises thought about cloud software. GP's point was a similar mental shift in how we write that software.
It seems like an ill-fitting adjective even in a vacuum, but what's worse is that "serverless" is commonly used to describe something that runs entirely client-side (e.g. p2p).
Just because AWS Lambda is a "mental shift" doesn't mean that "serverless" is a good way to describe it.
As for a better term, perhaps operationally-opaque or "pure service" are starting points? Service is correlated with stronger federation while p2p is decentralized as a rule. I'd rather avoid SOA which does not say anything about whether you have to manage the operations or dependencies - nobody is calling microservices as "server-less" after all. When people in companies talk about a "services" company they mean that the labor and overhead of management are all outsourced and as a customer you don't really care about how they operate as long as they don't violate certain OLAs and SLAs. AWS can run Lambda on marmot-based computing on Mars for all I care as long as it meets certain specs. Services compete on cost, SLAs (features are part of SLAs), and OLAs, period.
But there's another interesting thing that is relevant here. Because it is stateless, it it really is "serverless" in the sense of there being a single server associated with your code.
They really could run it in disposable VMs ZeroVM[1] style.
Not having to worry about anything else except the code opens other doors.