Awesome, one thing, what is the advantage of microservices, to lets say, modular monolith?

Scaling parts of the application independently from each other. If traffic spikes in one part of the application (e.x.: your image categorization web app was posted in a cat forum) more nodes can be added to that one resource to handle the load. Another reason could be worker processes that ran intermittently at midnight every day (e.x.: to email users top pics they missed that day).

Isn't that the whole point of the Erlang/Elixir/OTP actor model and BEAM VM? It seems like many systems with microservice architecture are reinventing that wheel only worse - except in the cases where the system needs to use legacy or polyglot services.

The difference is in the network boundaries. I write most of my code as microservices, but it would be incredibly easy to wrap it all up into a single binary.

It's not uncommon for go code to have one binary for separate microservice functions (see OKLog). This way you can change between a microservice, or a monolith (ish) with a CLI flag.