The paper seems to use 'microservices' to mean 'containers', but you can make microservices using serverless tech. Heck, you can easily run a monolith on serverless too.
Another example: the paper claims that for microservices (aka containers?), most of the security concerns remain for the app owner to deal with, whereas serverless hands much more of that off to the cloud provider. Not really true. The container-based services on GCP/AWS are almost exactly as compatible with the rest of their offerings as FaaS is. You can front container services with CDN/API gateway auth logic the same as you can for FaaS. In fact, you can do that for durable resources too.
"...In this paper, we review the current serverless architectures, abstract their
founding principles, and analyse them from the point of view of security. We
show the security shortcomings of the analysed serverless architectural paradigms,
and point to possible countermeasures..."
For that, I think Functions-as-a-service makes more sense. Or, Containers-as-a-Service if that's your poison.
For internal documents I've written, I position FaaS as one category of Serverless services (which includes others like Database as a Service (DBaaS), etc.).
In that model things like AWS Lambda and Google Cloud Functions are considered serverless, but so are Elastic Beanstalk, App Engine and Cloud Run.
Managing your own individual servers in something like EC2 or Cloud Compute is definitely something I would not consider serverless, and I think most people would agree with that.