My feeling on this is that if the job is small enough and infrequent enough, I don't care about its impact on other services so I can run it anywhere (and it's effectively free in such a case), and if it's large enough and frequent enough then setting up for it in Lambda every time is wasteful and I probably want a system (even if a small one) dedicated to the job, for probably less money. There's probably a sweet spot in there somewhere...but, it's not high on my list of things to integrate into my infrastructure.
google micro (1 cpu, 0.6GB ram): $0.006/hr
amazon nano (1 cpu, 0.5GB ram): $0.0065/hour
https://cloud.google.com/compute/pricing
https://aws.amazon.com/ec2/pricing/
in both cases, +disk, +traffic
The micro went from 0.6G to 1G ram in the 't2' generation, and the nano fills the need people have for the old micro size. I use them for bastion/nat boxes :)
My point is that when you compare apples to apples, it's really not all that different.
I've had a number of startup ideas that went nowhere, and it would've been handy to test & demo them without springing for the full $17/month for an EC2 t2.micro instance. Usually they have some key aspect that's prevented me from running them on Lambda (eg. you can't exactly run a hacked Node.js binary on Lambda, and sending push notifications from it requires going through SNS and adopting its API), but if I could run arbitrary code & third-party packages and pay for only the computing time I use, it's an attractive proposition.
In general you use AWS for convenience anyway - if you're concerned about minimizing costs, you can sometimes get 10x price/performance ratios by moving to dedicated hosting.