It doesn't sound like it's the 'serverless' hosting that is their issue, rather that they have no direct control over the endpoint that their difficult to upgrade client software is hitting. They actually fix it in future versions of the client software by putting controllable serverless endpoints in front of the firebase endpoints they're hitting, so if something like this occurs again they could just change their endpoint to not hit the third-party resource that is costing them so much money.
The more general problem with serverless architectures that this post illustrates is that you're essentially running on a series of FAAS/SAAS style services which can change their billing at any time.
So you either have to code a portability layer so you can move to another one in the event of an unwanted change (which could be quite a lot of work), or you accept the risk that a 3rd party could cost you a lot of money until you can change off their service (which could be quite technically challenging depending on the complexity of your use case and the availability of comparable alternatives)
Whilst with things like container services you retain more control (ultimately you can self-host if need be) as soon as you step onto pure serverless you'll always be at the mercy of the providers of the services you use.
I think they make it pretty clear the problem is with their inability to change the endpoint (i.e. the URL). Switching from lambda to something else could be a pain in the ass but they'd be hitting their own domain and changing where that points is relatively trivial. Right now they have clients out there hitting a Firebase endpoint that they have no control over and that they can't update quickly.
