A "real" microservice (according to some definitions) might be only really necessary for organizational reasons. But the services in a distributed monolith are also often called microservices (at least in my company). And for them I believe there is another good reason that I do not hear about in these discussions: robustness.

In our software project, we have had many issues with OOM and golang panics in a goroutine killing our critical endpoint even though the fault was most times caused in the administrational endpoints. By separating the critical endpoint from our administrational ones in two separate services, we reduced the criticality of those issues and therefore also the number of hotfixes we needed.

> But the services in a distributed monolith are also often called microservices (at least in my company).

I thought that was a "microlith".