In Play 2.0, Play delegated all requests to get through the actor. It depended heavily on the future Akka API and other parts.
In Play 2.1, with the transition of the future Akka API to Scala 2.10, Play began depending on what was not directly on Akka. It receives all execution contexts from Akka and provides integration with Akka, but this concerns its scope.
In Play 2.3, we are adding new features for Akka integration, especially in WebSockets.
In Play 2.4, Play will be ported to the new akka-http (formerly known as spray), after which the game will be built on Akka, as you can get.
What are the implications? Akka is a programming paradigm that simplifies concurrency. It also provides excellent abstractions for distributed programming - the most difficult thing in distributed programming is failure problems (which occur all the time), respectively. Most tools try to solve this problem, trying to hide the failures from you, but, unfortunately, hiding something does not make it go away and actually really complicates the situation, because when you try to solve specific types of failures, the fact that they hidden from you gets in the way. Akka pushes bad luck in your face, so when you code, you are forced to think about how your application will respond to crashes. Therefore, you are forced to develop / code your application in such a way that it is tolerant of failures. It also provides you with tools to solve these problems hierarchically, allowing you to specify at what level you want to deal with what type of failure and how to respond to the failure (die, repeat up to n times, etc.).
So how does this help play? The best question is how does it help the Play user? Akka helps me implement Play myself, but you can implement it without Akka (in fact, Netty does most of the hard work now, which will change in Play 2.4). The important thing is that Play seamlessly integrates with Akka, simplifies the processing of HTTP requests with actors, eliminates crashes, etc., and this helps to reproduce users, as it allows them to create their application in such a way that it is scalable and flexible.
UPDATE: The above was written 3 years ago, since then a lot has changed. Play 2.4 did provide experimental support for akka-http, but Play uses Netty by default.
In Play 2.5, we abandoned the iterative API and switched to Akka threads. This meant that now all asynchronous IOs passed through Akka threads. Soon (not sure if it will be Play 2.6 or later) Play will play a flip of a switch to make akka-http standard server backup support (although not yet a WS client).
UPDATE 2: Play 2.6 now makes akka-http the base version of the default HTTP server (Netty is still available as an option).