Simplicity implies a small set of features; it's a property of design.
Facility implies ease of use; it's a property of operation.
Go unambiguously favors simplicity, at the expense of facility. This is why we're given raw CSP primitives (sharp edges included, e.g.: goroutine leaks) instead of a full-fledged actor model.
A fallout from this is that you can have one actor supervise another, to protect your program from errors: https://hexdocs.pm/elixir/Supervisor.html
The Golang runtime provides only these actions: (spawn). It’s up to the author to create communication channels, and it’s impossible to query for the status of a Goroutine. This means you have no explicit control over goroutines, so you can’t kill misbehaving ones like you could in another language.
Anecdotally, 99% of the complaints I read WRT Go can be solved by using libraries that already exist. If one wants a batteries-included-in-the-stdlib form of facility, one should look at languages like Python.
In a pure actor model raw channels wouldn't be directly available and I would be required to push to and read from a concrete goroutine.