You can save your startup thousands of dollars per month on services, with very little effort -- if you know how.
A larger group of people would struggle with the effort to do so competently.
Energy spent bringing more people into the first group is generally a positive thing.
This is the common wisdom which is correct in many cases, but not all.
If you have a decent systems/infrastructure person in your startup, the incremental cost of running a lot of these kinds of services is effectively zero. If you are bootstrapped, this can be financially significant.
Most startups do not need a decent infra person on day one, and no one would recommend hiring one for this purpose. But if someone on the team has the skills, it can make a ton of sense to leverage them.
I think it's good to help people obtain these skills which add value to (or at least save money for) their project, and correspondingly enable more people to start up in the first place.
At the start-up we ran nothing ourselves, except the gitlab runners. (Well, except for the first month where a bunch of laptops are used to prototype the app). I spent my first year writing terraform and helping design the product for low-cost scalability. So much of what we did for that whole year was in the free tier that our runway money could cover team building. 1 year in, I could deploy our entire stack from scratch into a new region in under an hour. VPC, subnets, security rules, IAM, queues, workers, Kubernetes cluster with autoscaling nodes, databases, DNS, CDN, monitoring, metrics, email (AWS SES)...
That type of fast deployability to a new region shouldn't be a late consideration after you've spent a year tinkering with in-house stuff. In fact, getting to another round of funding requires that you have that stuff ironed out. Can you support FedRAMP requirements? Yes, because that was a day one consideration. How about GDPR? Ditto. Do you have separate dev, test and prod environments which are identical apart from scale/cost? Yep!
Right now I'm working with a company that built everything in-house, from the perspective of "one single data center". It's a disaster. If you're not thinking at scale from the start, your probably not doing basic stuff like proper naming conventions, non-clashing CIDR. They're using all the right tools, but badly. Their terraform is a mess because it was obviously introduced it gradually on top of existing "snowflake" infrastructure. Their next data center was pretty much copy-paste followed by a thousand changes. And their code coverage is low - lots of stuff still manually created. (This is a known company with a decent product and lots of customers!). All of the people hired to try to make it scalable after the fact are saying things like "...it would be easier to just throw it all out and start over".
The problem with doing things badly because you think you can improve it later is that suddenly you've got customers on this thing, and you can't start over.