I agree that it only really makes sense to consider when you have runtime concerns around performance that justify the added complexity. I posted that in a comment elsewhere. However, I think the benefit to modularity can be significant sometimes. Separating something into libraries is an exercise in organizational discipline, and in my experience it often fails. An inviolable boundary can be valuable for orgs who struggle with that sort of thing.

That said, even small apps virtually always have hot regions. Typically those can be ignored until big scale without impacting the users, but that doesn't mean it's efficient to do so.

I would also definitely push back on the idea that a monolith is inherently more compute/energy efficient. I'm not sure how you arrived at that conclusion, but it doesn't take much in the way of efficiency gained from individually scaling services to make up for the tiny additional costs of your orchestration/communication.

Personally I'm a monolith guy. I think the discipline required to build and release a good monolith is typically easier than the difficulty of maintaining services. I would rarely recommend a microservice architecture. But I don't think it's in anyone's best interests to just pretend that the benefits of microservices don't exist.