Containers are not appropriate for some scenarios. If your threat model is "attacker has arbitrary code execution" you should be very wary of a container holding them for long - you're one kernel privesc away from a container escape. It's nice to have if your situation is "first the attacker would need to exploit my service and then they'd have code exec", but if you provide RCE as a service a normal container is just not a good barrier.

By contrast, running attacker code in Firecracker is much safer - for one thing, the attacker needs to escalate within the VM in order to then expose the necessary primitives to then escape the VM. So it immediately adds an additional required vuln. But also, instead of the entire Linux kernel being the attack surface (it is for the first vuln, but...) you have to attack a much smaller codebase that implements the VM.

In the case of Firecracker this is really hard and, depending on your exploit, if you end up controlling the Firecracker VM itself you're actually in yet another sandbox - so you now need another vuln to escape (although that sandbox is not amazing imo).

Run multiple workloads on the same CPU that you don't fully trust. VM-based containers will force the CPU to properly context switch between guests (e.g. using VMENTER on x86), normal process-based containers won't.

Many serverless services use MicroVM rather because they think containers doesn't have enough isolation (=insecure?) to run untrusted code.