"So, just like when using a local VM, e.g. a Vagrantbox"
I don't think this an accurate representation. A VM or a container works with many dependencies that still needs to be maintained by the dev team, e.g., OS of choice, tweaks in ports, custom environments likes timezones etc; A Lambda, per example, you just need to choose a runtime target, a memory size and you are done besides of course the lib dependencies of your code. You even don't need provision the Vagrant config that in the real world in my experience is really messy sometimes with developers getting problems on their own VMs.
"There's still just as much Server there as otherwise. "
For sure. But in this model you don't have the overhead to manage, patch and so on. Serverless naming is somewhat misleading. In reality, as I see, is just an abstraction for the infrastructure. For small teams, per example, is not practical create a CI/CD pipeline. You just don't have time or even someone with all the know how to build, and the most important, maintain. Some of the serverless managed services provided this out of the box. I'm not trying to convince you otherwise of your choices and as Mark Richards and Neal Ford put in "Fundamentals of Software Architecture: An Engineering Approach", "Everything in software architecture is a trade-off", adding that if someone doesn't seem a trade off in a decision is because it just not found it yet. So, for sure there are trade off and some teams and individuals will likely run bare metal and manage all the things, but I wouldn't dismiss so bluntly a very large set of offerings and possibilities developers can leverage with the serverless ecosysteam.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
"So, just like when using a local VM, e.g. a Vagrantbox"
I don't think this an accurate representation. A VM or a container works with many dependencies that still needs to be maintained by the dev team, e.g., OS of choice, tweaks in ports, custom environments likes timezones etc; A Lambda, per example, you just need to choose a runtime target, a memory size and you are done besides of course the lib dependencies of your code. You even don't need provision the Vagrant config that in the real world in my experience is really messy sometimes with developers getting problems on their own VMs.
"There's still just as much Server there as otherwise. "
For sure. But in this model you don't have the overhead to manage, patch and so on. Serverless naming is somewhat misleading. In reality, as I see, is just an abstraction for the infrastructure. For small teams, per example, is not practical create a CI/CD pipeline. You just don't have time or even someone with all the know how to build, and the most important, maintain. Some of the serverless managed services provided this out of the box. I'm not trying to convince you otherwise of your choices and as Mark Richards and Neal Ford put in "Fundamentals of Software Architecture: An Engineering Approach", "Everything in software architecture is a trade-off", adding that if someone doesn't seem a trade off in a decision is because it just not found it yet. So, for sure there are trade off and some teams and individuals will likely run bare metal and manage all the things, but I wouldn't dismiss so bluntly a very large set of offerings and possibilities developers can leverage with the serverless ecosysteam.