Whether a microservice that you design and develop requires authentication is up to your functional requirements and the way you design it.
A common technique used is to not have authentication on each individual microservice but to group them together behind a common fascade (such as an API Manager). You can then apply authentication and other policies at one place - the policy enforcement point/API Manager - for "external" consumers while "internally", behind your common security boundary, your microservices remain lightweight and can call each other without authentication (if that makes sense for your usecase/requirements/architecture etc. etc.)
To sum up - it's a design decision that involves multiple tradeoffs.
Clearly, if you have a critical business service fetching or updating sensitive data, you might want only authorised callers to access it. But you might not want many internal callers (could be other microservices) running within your organisation's "trusted" network to be burdened with unnecessary policy enforcement.
But then, there might be situations where even internal callers need to authenticate properly (e.g. if it is a payment service)