At the risk of committing a "No True Scotsman" fallacy, what you're talking about is not really what people are talking about when they are discussing the tradeoffs of a microservices architecture.
While "microservice" obviously literally means a small service, when people talk about microservice architecture they're usually talking about building out applications that look like a single service to the end-user but in reality are a whole bunch of small services that talk to each other.
Just creating a small service that exposes a small piece of functionality is clearly the right thing to do in many cases, but that's not what the discussion about microservices architectures is really about.
I have a little website that I maintain personally and it consists of distinct services for auth, analytics, comments, and a fileserver for static HTML (also a bunch of cronjobs for backing up databases and so on). It runs on Kubernetes on a couple of Raspberry Pis in my office. These services are sort of distinct, but several collaborate with the auth service.
Some would say this is overkill and they're probably right (although I would argue that it's not overkill to the degree that most on this forum would initially believe), but I haven't had any real issues with the microservice architecture; however, I do like that each service has its own secrets--the comments service doesn't have access to the auth service's private key or database credentials so if it gets pwned the blast radius is more limited. Similarly, I will be able to create network policies to lock these services down so they can only talk to their collaborators (defense in depth). Maybe there are some analogues in the Java or .Net VMs for these isolation techniques, but I don't think there's any general analog.
That said, there is some amount of infrastructure overhead for each service (each service likely needs its own CD pipeline, DNS, letsencrypt certs, database, etc) but these are all managed via infrastructure as code so I can basically just stamp out these services with little effort.
I have plans for NFS, mastodon, and media services all of which are third party and thus it wouldn't be desirable to integrate them into a monolith, but I'll be able to take advantage of my infrastructure as code automation to stamp out these services (which is mostly to say that "monolith" doesn't really absolve you from needing to manage many services anyway).
In general, I've not had the sorts of problems that people complain about with respect to microservices with my personal project, nor with my work projects at various prior employers. I'm not sure what the difference is--maybe I've been graced with good architecture? That said, I have worked on monoliths that were pretty bad experiences, and I think a big part of this was that it was too easy for teams to thoughtlessly extend the interfaces between components which degrades the architecture over time (conversely, I posit that microservices make it more difficult to change interfaces and thus there needs to be a more compelling reason). This is just speculation based on my experiences; I don't intend for it to seem authoritative.
While "microservice" obviously literally means a small service, when people talk about microservice architecture they're usually talking about building out applications that look like a single service to the end-user but in reality are a whole bunch of small services that talk to each other.
Just creating a small service that exposes a small piece of functionality is clearly the right thing to do in many cases, but that's not what the discussion about microservices architectures is really about.