And maintenence and onboarding.. I guess to find the right balance is the key. I tend to go with monolith and use microservices to offload heavy dutie tasks or to benefit from other languages and framework when they are a better fit for a specific problem domain

That doesn't sound like "microservices", but like a monolith with a few services split out where it makes sense. People have been doing that for a million years, long before the web and certainly long before "microservices" was coined. It's just "using common sense" basically.

I'm not aware of such nuanced definitions. For me a microservice is a one endpoint service, designed to do one task, with full introspection, and deployed on the "cloud". As fair as I know, I can orchestrate them with monoliths and they still microservices.. or where you draw the line between services and microservices? The size of the service itself or with whom it interacts?

There is no One True Definition™, but I think most people understand "microservices" as "an application where splitting the functionality up in small services is core of the architecture", or something along those lines.

"We split off 2 things in to small services because it made sense" is rather different. I mean, I don't really care if you call this 'microservices" I guess, but it is different, right?

yup, monolith goes very long only to the point where you have hundreds of engineers or some very specific niche technical problem that I would start thinking about microservices.