Most of the hatred towards microservices is probably better directed at REST, which is a good paradigm for serving documents to web browsers but is overcomplicated for microservices. RPC is a good alternative, and gRPC is a good implementation of it.
[1] My phone autocorrected this to “deplorable”, which is also a good adjective for a monolithic web application that contains lots of libraries and is only deployable as one artifact.
If you release a new version 1.1.0 of a library you have to update and redeploy all applications that use this library.
If you understand binary compatibility you can deploy a library without deploying its client applications/libraries (they would need to be restarted, however).
In fact, this is one of the very reasons people invented shared libraries! It's why, for example, Linux distros are based on shared libraries: one can update large swaths of the system by updating a single package.
If your languages don't support this then it would be very unfortunate indeed.
You can do that by several different ways. Overall, if one wants a "one size fits all" answer to how to break code into teams, it is by breaking the code into libraries, not services. Services are a niche tech here, to be considered when the others won't suffice.
> if you need to scale the (monolith) service and it is too expensive to just scale it n times.
Again, nearly every time this happens, the correct answer is to refactor the monolith so replicating it scales. Services are only for those cases where this won't suffice.
I don't think I disagree with how you think. But I do think your comment is easily misunderstood and harmful without those qualifiers.