Earlier quoted context omitted.
On any platform?
It has the ability to make real-world concurrency scenarios trivial e.g. * 3 fibers - each fetches from remote storage, local storage and in-memory cache. * Race them, kill the two slowest and give me the result. * Free the resources safely including if any of the connections fails for an unforeseen reason. That's a few lines in ZIO. Pain to get working properly in Java, Rust, Go, C++ at least.
Unfortunately, all libraries that abstract concurrency on an application-level break the ability to get meaningful stack traces. At least all the ones I know of, including ZIO, Akka, Monix, plain Futures, etc. I know that there is tooling to counteract that (such as the abstractions used in distributed tracing), but that's again on the language level.
In my experience, for all but the most advanced applications, the debuggability advantages of using linear code outweigh the performance advantages gained by abstracting over execution contexts. Thus, I would posit that concurrency is best dealt with on the platform, not the language level, especially when starting a project.
Of course there are some situations where a library can make some concurrency task appear trivial, but as long as there is no good tooling, the time saved using beautiful abstractions tends to be paid back 5-fold when those abstraction break (which they often do as an application grows).