I think you are repeating a strawman argument against microservices that doesn't always hold.
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.
Email just sounds like a regular service. Separate SMTP servers where you encapsulate all of your logic of email dispatch frequency, retries, etc has been pretty standard for a long time.
> 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.
because the email logic was spread out everywhere and called from multiple apps
so it doesn't sound like a counterpoint to me - you didn't start off with the email service, and only split it off after it was already established across multiple entities. Plus, you added a bunch of justifications for this, i.e you could "bring a strong argument in favor of it" - so where is the strawman in your examples?
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.