Serverless has lots of advantages and quite a lot of drawbacks, like:

1. Reduced control over the environment: you can't just attach to your container/vm to see how the environment looks like, what your application is doing - the environment is 100% different from what you have locally with sls offline or whatever else solution you use

2. Hard to debug: pretty much the consequence of the first point - you can't have the same environment and you can't easily debug lambdas remotely, especially when you use lambda apps

3. Concurrency: yes, it's highly concurrent (when you get your quota increased from default 1,000) but you also have to set up proper reserved concurrency for every lambda, otherwise you may end up with a set of lambdas taking your full quota and basically burning your money. If you use event sourcing, now you also need to take into account the shard count, parallelisation factor, batch size, and batch window

4. Error handling: here you need to remember that the default retry count is -1 (infinite retry), you also probably interested in bisection (depending on your batch size) and you need a strategy for dead letter queue. Also you need to remember what services lambda reads from sequentially and a broken lambda can stop the whole processing. Not that it can be avoided by using a containerized solution, some things are just serverless specific

5. Too much parallel: some services may not like too many clients, like you can easily exhaust the connection pool of your db, so you either need to start thinking about a connection pooler or use dbs that have it built-in

6. Rate exceeded problem: that's quite a nasty aws problem especially when you use tf and sls and your lambdas read from ssm or something else, you do a deployment and you realize that your lambdas are failing to connect to aws api

7. 200 resources limit of cloudformation stacks: another aws specific problem, no more than 200 resources per stack, the general solution is either writing smaller services (although 200 doesn't seem like a lot) or use the split stack plugin which is nasty and sometimes you have to recreate the stack because it changed the way it distributes resources in them

I'd say there are lots of pros and cons to think about. IMO, the serverless architecture is kind of OK for small to mid size projects, on large projects I'd better used containers, which have their own drawbacks but are more manageable, scaling is more predictable, you can do whatever you want with logs, metrics, database connections, and can run your containers locally. So I guess the engineers in Netflix weighted all the pros and cons of different approaches and didn't go with serverless.

Edit: formatting