Going beyond the vendor lock-in, one of the biggest initial draws of serverless - from speaking with friends - has been simplicity in situations where state isn't a concern. On the other hand, here we're discussing a bunch of hoop jumping to get stateful functionality that might more easily achieved by adding a library such as SignalR, or socket.io into your app.
Whilst this is probably a few screens to set up via the AWS, and can obviously be automated, you add complexity to development and delivery. Critically you also make it harder to diagnose and fix problems.
Like anything it's a trade-off: for some apps these issues won't matter so much, for others they will. For us, it would definitely be a problem.
Serverless is a tool with good use cases where your tradeoff-win will be great scalability. It's not that great for general use (yet) IMHO.
You can create a "session" in redis pretty easily if you're willing to add another database as a requirement. That way you can share state.
It's also very new so the ecosystem will keep maturing and enabling more use-cases.
Whilst this is probably a few screens to set up via the AWS, and can obviously be automated, you add complexity to development and delivery. Critically you also make it harder to diagnose and fix problems.
Like anything it's a trade-off: for some apps these issues won't matter so much, for others they will. For us, it would definitely be a problem.