This has been covered in Future of Swift-NIO in light of Concurrency Roadmap.
The short version is that the core of SwiftNIO does not change, because we cannot meet our performance guarantees under the concurrency proposal as it stands today. We have a _NIOConcurrency module available that adds a number of entry points for concurrency support. This allows interop between NIO and concurrency programs.
In general we expect the high-level NIO wrappers such as async-http-client and grpc-swift to adopt concurrency wholesale, and essentially to remove EventLoopFuture from their APIs. Most users should not need to interact with NIO directly, and so those users should be able to essentially forget that it exists.
In the fullness of time, as concurrency matures, we'll re-evaluate. In particular, custom executors would be an opportunity to investigate more substantial adoption of concurrency. With that said, NIO is at its core almost entirely synchronous, and needs to be able to park its event loop threads in selectors. This is not something concurrency supports today, so the fundamental low levels of NIO will not change until that changes.