Engineer induced complexity is also common. I've never heard about management pushing for a scalable, event-driven, microservice based architecture when a simple monolith serving a few thousand daily users would be just fine.
1. an engineer under management pressure couldn't easily take an expedient dependency on the private internals of another system
2. teams could deploy their changes on their own cadence, so they didn't feel additional pressure to squeeze poorly-conceived things into one less-frequent release (many frequent releases are theoretically possible for monoliths, but much rarer for pretty understandable reasons)
Moreover, reliability improves because of the aforementioned reduced complexity but also because the blast radius for a reliability issue is scoped to the service, and security improves for the same "blast radius" reason (an attacker who compromises a component can only access that component's secrets and can only talk to that component's collaborators).
My suspicion is that microservices work very well when an organization has a strong architecture/SRE capability irrespective of management or product development capabilities, whereas a monolith depends on all capabilities firing on all cylinders.
The net complexity may well be (and often is IME) less for a microservice than for an otherwise similar monolith. In addition to this net complexity discussion, microservices also have security, scalability, and reliability benefits.
I agree. If both team size and code base are small, the scalability is not needed and the domain logic isn't too complicated, microservices add an overhead with very limited benefits.
If you have different teams for each service - great. If you the same person is working on multiple services - probably a premature move to a more complicated architecture.