You really have to have extremely unpredictable and spikey needs as well as need the processing immediately. Because if the traffic is predictable, you can schedule spot instances for much cheaper and same for if the data doesn't have to be processed immediately.
To me, the best use cases are very infrequent, spikey, brief needs. I haven't seen a lot of examples that meet that.
The 1% in functions was for processing large PDF files where users were sitting their looking at a progress bar waiting for the file to be processed in real time.
Another use case might be for something that is very low load, and say you have a lot of these services you may not want a VM for each one. However Docker provides a nicer solution for that: Get a VM (reserve if required) and run some kind of Docker host/orchestration on it, and run all your little services from there.
I will gladly pay (Amazon|Google|Microsoft|Cloudflare|Zeit) to manage software deployment infrastructure for me, allowing my teams to concentrate on writing business logic. As with any other concept, it has a learning curve, but once you're comfortable with the concepts, your development will speed up, no question about it.
Just yesterday i put the 'dnspython' module behind a google cloud function and all it took was 5 minutes and i had a REST interface to query MX records. It's great for small little use cases like that.
Another use case might be a simple webhook, where you're receiving pings from an external service and all the serverless function does is save it to a DB and maybe trigger another task for it.
In cases like this you can skip a lot of the devops boilerplate and reduce it a single file containing your function and perhaps a requirements.txt(or whatever manages your dependencies)
I don't have anything against FaaS as a concept, but it almost always leads to crappy operation. The simplest examples of it working are crowded out by the attempts that ended up redesigned as normal applications.