You can achieve the functionality using both ways and its actually an opinion based question but I would still try to list pros and cons based on my experience.
I am assuming here that mongoDB is your source of truth for data, while ES is used only for search.
Updating the ES(Elasticsearch) in the same application, after updating the mongo.
This would save you the extra overhead which microservice brings: like deploying another app, infra, releasing the jar which contains the same POJO or entities, used by your mongo and ES application. Major overhead is the extra network hop, as if in this case, once update is successful in your mongo app, then you would send the request to ES app, which in turns update the elasticsearch application, you can send request parallelly to Elasticsearch app but this would lead to inconsistency, As an update might fail in MongoDB, hence both ES and MongoDB will not be in sync.
Creating separate micro-service for Elasticsearch
As long as you managed the consistency between your source of truth and elasticsearch, would bring you the typical benefits of microservice, like separation of concern, faster release cycle, less complex code, choice of language and frameworks etc, improved developers productivity, etc.
Again, your question is not specific to elasticsearch and it's more of a microservice vs monolith which totally depends on your use case and you can find a lot of debate on these online, but one you should definitely watch and is one of my favorites is uber architect's regret on scaling it to 1000 microservices.