You can't evaluate a technology by looking at drawbacks alone, you have to consider the benefits as well, and whether they outweigh the drawbacks.
I'm sure Stallman couldn't use the iphone when it came out because of constraints, that doesn't mean the iphone ever was DoA.
Now, short-term projects that can disappear in a few years or less have less risk for lock-in. We still see those disrupted on occasion when the vendor abruptly disappears. Users had to redo their work, which wouldn't have been necessary in lock-in free approach.
We're "locked in" to AWS - in that it would take a massive effort to move to Google/bare metal, despite not using any AWS-written servers (that is, we're FreeBSD, MySQL, Redis, etc.). But the benefits of AWS have been huge for us, and anyone saying they're outweighed by the potential downside has no idea what they're on about.
The right tool for the job is sometimes a vendor with specific services that, yes, sometimes have a lock-in component, even for long-term use.
In this specific case this particular BaaS implementation may not be full-cooked enough to entice you onto it, but saying vendor lock-in is bad as a blanket statement or incontrovertible truth is just silly.
For that matter, any number of proprietary languages have been successful over the years. If it solves a problem, and solves it better and faster than reinventing the wheel, most businesses will use it. Time-to-market is a much bigger deal than abstract concerns about future platform change. I've been in this industry for 20-odd years, and the only things I've seen last are Unix and SQL. Everything else is new since I started. I sometimes work with bleeding edge, and I'm not afraid.
If infrastructure is really 90% of your code work and you can't salvage business logic in a platform change that doesn't require a new language, the problem isn't the serverless architecture.
I've been using lambda lately and perhaps 5% of the code in my Lambdas is AWS-specific; the vast majority was rapidly extracted from existing projects, wrapped in a simple Lambda interface, and done.
While I don't advocate Lambda for everything, there's almost nothing there to lock you in - its a simple function that accepts two parameters. Even coupled with API Gateway, its just moving my routes definition to a slightly different layer. I could easily port any of this work back to any common Web framework with almost zero effort. I won't, because Lambda solves actual problems for me now.
Not theoretical: Microsoft, Borland, IBM, HP, Oracle/Sun... all did it at least once with Microsoft doing it many times. They're not open, which drives up the cost of exiting dramatically.
If you feel locked in, you lift-and-shift your serverless logic to a new platform. Write some shims and wrappers. It ain't that goddamn hard.
Any kind of practice without such setup means you've decided to let the vendor control your situation ftom that point onward. Historically, from mainframes to servers yo desktop to mobile, this always led to less brnefits overtime where new, better stuff emerged that locked-in customers couldnt use at all or benefit as much as they liked. Those that avoided lockin could. Worse, some locked-in got hit with price hikes or even EOL'd products.
So, I think the default should be justifying a lock-in product rather than the other way around. Ive seen situations where it made sense. My comment mentioned one. It just rarely does esp today with so many cheap, flexible, and so on alternatives to commercial lock-ins.
So, the question instead is "With these requirements, which products and services meet them with good, cost-benefit analysis? And which is best when benefits and liabilities are considered?"
I have seen people waste precious time and energy on "open" solutions, and lose focus on other, important things. I'd rather be stuck extricating myself from some lousy vendor relationship than not selling my product.
For a particular use you certainly can. Some problems have hard constraints. Freedom from lockin is a common one.