Lambdas are a bit more "serverless" than most things as they can be spun up anywhere and you're just coding to the entry method signature that passes you some request context.

I think we all understand that it's got to run somewhere, and I too sort of bristle at a marketing driven statement throwing around terms like serverless- but I am finding it to be a mental/verbal shortcut more and more these days.

If you mean to imply that your code will (likely) run with no local configuration state, all your local work will be ephemeral and will need to be pushed out to persistent storage like NAS/SAN, DB, etc, or that you'll need to raise events for others to do more work like sending messages on a queue or an RPC/API call to another end point- then yeah, I'll take that and be okay with it. If that is our shortcut I'm okay with using the term serverless when we all know darn well it's got to run somewhere.

Its just an abstraction though. And it falls apart and becomes full of implementation details when the actual fact that its running on a warmed up or cold server causes issues

It is, but once you agree on the context it provides, it can be a word that is useful when describing how you plan to deploy some section of code.

We use Lambdas for a bunch of different async work tasks like PDF generation and such. Warm or cold doesn't matter at all for us.

If you're trying the super 'serverless' approach of using AWS API services backed by Lambdas, then yeah, warm/cold will definitely matter.

When I think "serverless" I think this: http://unhosted.org/

That describes a model where a web paged is permanently cached in a browser's data. Effectively reducing the server to a binary distribution system.