My work is heavy serverless and nobody I work with has had any luck with Localstack, myself included. It's just too limited, fragile, and buggy to work for anything we do. Our stack isn't anything particularly unusual either, it's just that if you are using Lambdas heavily they are probably tied in with a whole bunch of other AWS services in ways that are hard to replicate locally; and Localstack just isn't up to the task.
While there are some nice benefits to serverless workloads on AWS, local development and reproing production bugs are major weak points.
SAM local isn't a perfect emulation of the cloud based lambda environment. This is why AWS SAM added the "Accelerate" feature, making it easier to deploy code to the cloud for testing purposes.
It's alright, but continued to find bugs and edges cases with it. The challenge is when there are a bunch of integrations cross-accounts, eventbridge, cloudwatch, etc. that you just can't emulate well locally. Or once you do, it doesn't work a month from now because things change (e.g. a developer is using a new feature that isn't supported by localstack or something). In container land, you don't have to worry about these cloud integrations. You just spin up the services you want in a docker compose file, k8s deployments, helm charts, etc. and you basically have everything without having to worry about being a AWS specific blackbelt guru expert.
You just have to be a Kubernetes black belt guru expert. It is better but it’s not all rainbows and butterflies on this side of the fence either. Generally it boils down to the stack taking way too many resources to run locally, or still needing access to various persistent data stores, etc..
You don't have to run kubernetes for containers, but even then, only 4 of our engineers know and operate kubernetes. It allows us to enforce routing, authn, and authz standards everywhere (and test locally). Application engineers only need a simple command to run their stack and some code templates to build and test applications. Not much knowledge is typically needed on their part. Is it always perfect? No, but it's a lot simpler then wiring up a bunch of vendor specific offerings.
I use https://github.com/rimutaka/lambda-debug-proxy to run Lambdas locally while still being part of the AWS pipeline. It eliminates the need to emulate the input/output. That tool is for Rust only, but there is no reason why it can't be ported to other languages.
While there are some nice benefits to serverless workloads on AWS, local development and reproing production bugs are major weak points.