I think the issue is the definition of a microservice isn't really set, while those are good candidates for microservices, you can even design them for core functionalities, such as for example in some challenger banks, i've seen the architecture of one or two who would have a service for different functionalities,such as one for card transactions, one for dealing with the account balances, etc.

But in my experience atleast, one of the biggest issues with microservices is the speed impact. Even a difference of 100ms on a consumer facing application can be an issue. 200ms is a noticable delay, and if something is 1 second slower users will actually get pretty frustrated. As for speed, the difference in speed can be massive, and JSON serialization/deserialization (the way it is commonly implemented atleast) is very compute heavy especially if it relies on reflection. So the speed difference can sometimes be 5-10x and in microservices is a bigger concern then network latency. When you're dealing with larger dataset this becomes even more obvious.

Using gRPC for example, instead of JSON, the difference can be a couple of hundred milliseconds, which changes the conversation entirely on whether or not splitting it into a microservice is worth while and if the end user will notice the impact.