I'm not sure this one is a good argument for microservices. Having 100 copies of a microservice isn't any easier than having 110 copies of a monolith.
Any kind of competent code division is done because the divided interface is simpler than what you'll get without the division. So, go with the sibling here, and divide your code only if you have a very enticing interface that will be good to isolate and reuse. Doing high-level architecture decision because of operational details is almost guaranteed to lead you into disaster. You can do a few of them ever, so if you do it, it's better be one of your main differentials.
If you're loading a bunch of code in memory you don't end up using, you're wasting memory. Depending on how modular your code is, you may end up loading other external dependencies that don't get used (like initializing database connections). Likewise, for containers, you can usually make the container image smaller reducing data transfer, reducing Docker pull time, reducing host IOPs to unpack the image.
A lot of those problems can be optimized around, but sometimes it's quite a bit of work if you're already on a platform or framework that makes assumptions
If you're not deploying or scaling often and you have other mitigations like lazy loading to reduce memory, there may be no advantage.
Microservices are about domains of logic and form nice clear boundaries. They don't necessarily need inter-service comms or much by way of environment setup/maintenance. We have an email microservice that was split up that way because the email logic was spread out everywhere and called from multiple apps. A microservice was a good way to encapsulate all of the email logic into a single place with a clean interface. We can make all sorts of centralised changes without affecting any of the apps. We can also scale it out as the amount of email we need to send increases.
> encapsulate all of the email logic into a single place with a clean interface
You can encapsulate and put stuff behind an interface with libraries too. This is not the value proposition of microservices.
don't build microservices to start off with
because the email logic was spread out everywhere and called from multiple apps
One thing to always keep in mind is the 'choose boring technology' mantra; prefer using existing technology (e.g. languages, API technologies, front-end libraries) over adding new ones. Every new tech adds complexity, or another node in a graph.
Also, avoid microservices. That is, don't build microservices to start off with, because you're most likely making the wrong abstraction, and you're adding a ton of overhead (inter-service communication, logging, tracing, envirionment setup, etc). Splitting off services is fine as long as you can bring a strong argument in favor of it (e.g. performance, if one aspect of your application is hit 10-100x as hard).
But in practice, in most applications, you don't need microservices. You will need scalable services, but those don't have to be 'micro' per se. Also don't get hung up on the 'micro' in the name, size should never be a reason to break up a monolith.