I've had a good experience with microservices, come on:
Teaming: When your system grows and the development team also comes up with the need to break down a large team into smaller teams to facilitate communication and division of tasks. With the microservice paradigm, teams can attack different services without the risk of one change affecting the development of the other team (collisions in merges, etc.).
Selective Scalability: When you need more performance in the monolithic model you typically double the entire server or increase its capacity. With microservices (or any distributed system paradigm), you can scale only the part of the system that really needs more performance, without touching the rest.
Development Speed : This part only applies after that your whole system is already well mature and I'm talking about part of the code only. Smaller solutions compile faster and are easier to work with.
Freedom to choose technologies: Each microservice can be written in the language and use the most interesting database to solve that specific problem. New technologies / frameworks can be tested quickly and closely.
Rapid Framework Update: As each microservice is independent, it is easier to upload the version of a certain framework without fear of side-effects in other parts of the system. The work is also smaller, as the solution is quite small and can simply be rewritten if this is the case.
Setup: The setup of your application can be much longer depending on its context. One has to think about API Gateways, service discovery and all the orchestration of microservices, things that are not normally needed in monolithic applications.
CORS: If you make AJAX calls to multiple services, you may have the CORS problem. This can be solved with a reverse Gateway / Proxy API (more work, more items to manage).
Authentication: The same thing as CORS can be solved in many ways (API Gateways + tokens for example), but it generates much more work in the beginning.
Logs: Logs are decentralized and should be centralized somewhere for full diagnostics.
Deploy: This is the worst part. If you already have problems deploying with your monolithic application, do not even think about microservices. All problems will be multiplied by the number of services, since instead of 1 single and simple deploy, you have to do several.
Test: Testing the application as a whole gives a lot more work on each developer's sandbox. Debug from end to end becomes more complex since you will be working with each service. Container technologies can help.
API Gateway Bottleneck: If you have a team taking care of the Gateway API, it can turn your development bottleneck if in your case each new functionality has to go through.
Backup: As each microservice ends up having its separate database, you will have many more backups to do and manage.
Transactions: With multiple databases you will have the problem of distributed transactions and perhaps some data replication.
The Microservice paradigm is fashionable and a lot of people are using it without stopping to think about the pros and cons. There's nothing wrong with monolithic applications, it all depends on your context.
As with any decision to use some technology, the question you have to ask is:
What problem do I want to solve with microservices? And what problems will I introduce with them? Is it worth it?
And one last tip:
If your company does not have a strong culture of devops , forget Microservices. Encourage and strengthen this culture and only when you are very good at it start to think about this paradigm. Deploy will be a key part in the success or failure of such a system.