I feel like this swings back and forth because neither monolithic nor microservice approaches completely solve the problem. You want some separation because it allows you to scale just the parts that need scaling, without paying the multiplier cost for the parts that aren't being stressed. You want homogeneity because of the additional operational burden of managing too many little services. Yet you also sometimes want a way to roll out upgrades/migrations one piece at a time, back to front, with monitoring and testing throughout, and this can go a lot smoother when the pieces are already separate. And yet you also don't want to get used to a system that has multiple different versions of various dependencies, and putting them in one binary with statically-compiled dependencies helps a ton. Except when you don't have much choice because different internal dependencies depend on different versions of external dependencies, but you have some control over that and can pay the up-front cost of ONE-VERSIONing your vendorized third-party source. I could go on, but probably the best thing to do is pick a design, maybe even a hybrid of mono/micro, and stick with it.

> We smashed the good ideas apart and are now trying to glue them back together over the network. But it is choice that creates many of the "challenges" and to what end?

This seems to be an example of what you say: "CIAM differs from IAM because customers behave differently than employees. They expect easy registration, social login options, and self-service capabilities."

There's really no reason to do this in two different systems.