It's like a library that you can call regardless of language ecosystem.

I joined a company that had a large, old, and mature selection of services written in PHP. If I'd tried to rewrite that mature code in a different language I probably would have wasted a lot of time for little benefit. If I'd had to write new code in PHP just to access old code as libraries that would have been a problem too. But functionality was exposed over HTTP APIs that could be used from any language, any runtime.

Well you don't want to call a processor intensive task with a library. A separate service for these types of tasks is a better architecture.

Although I'm not sure whether or not a task queue architecture with separate server workers executing code passed over from a central monolithic app server is still considered a "microservice" architecture.

Closer to command line tools in systems where you can just pipe output around in to whatever you want.

well a library + deploying it into its own space so that it doesn't bring down your main app due to compute time.

The operational part of microservices can end up being pretty important in these cases

HTTP-as-an-ABI