A Lambda deployment has the advantage that no one needs to manage it, and faults are isolated between clients. You could argue that if you need these properties your engineering organization has deeper flaws, and you'd be right, but in many companies engineers need to make do with what they get.
I assure you that somebody does need to manage it, and if nobody is you are going to eventually hit the wall at speed.
I've been called into SEV-1 issues where a Lambda-based web app spontaneously disappeared. (Seasoned AWS heads can probably make a guess as to why.)
You can always tell who has had to live with non-trivial serverless systems in Prod and who is just parroting the marketing copy.
They're very useful to react to events; but they also impose a lock-in.
For (very) light usage I feel they're ok. But this is an opinionated feeling.
If you want to process a lot of stuff, you need one (or several) instances.
If you take a close look at other 'serverless' offerings like KNative in K8s. They do something similar to launching daemon processes but they do launch pods and containers. If you already have K8s, it could be very useful. If not, use a message queue and instances.
Lambda is not cost effective in the CPU/RAM that you get compared to regular instances. It only comes out ahead for very intermittent workloads.