The goal of microservices isn't to have many (no pun intended) "micro" "services" doing each a little bit of work, but to allow an organization to deploy parts of an application separately.
Even if all the two 64-core 128GB nodes on the cluster run copies of all the two services.
When an organization is large and siloed, there is value in decoupling different parts of the application, assuming the ownership and expertise are properly distributed.
As the comment below mentions, microservices is a fashion–one that took off among overly-staffed eng teams. Having separate parts of the app to deploy can be a liability for a small team frequently deploying breaking changes.
I'd argue that lose coupling is a core principle of good software architecture. Bing able to deploy separately only makes it more convenient to manage.
> frequently deploying breaking changes
That's never a good sign. Frequently deploying, yes. Frequently breaking, not so much.
Even if all the two 64-core 128GB nodes on the cluster run copies of all the two services.