I think at this point either would be a good pick. Here's why...
I haven't used Libdx, but I've perused their site. I think both projects look pretty good. If I were picking a Game Engine my decision would come down to features, stability and support.
Starting with support, both projects seem to have pretty dedicated contributors. Michael Bayne of PlayN is a machine of a coder. Mario of BadLogicGames (libgdx) seems to be pretty dedicated. Both projects seem to have a healthy group of contributors & advocates.
Regarding features, they seem to be pretty evenly matched. Both will make creating a 2D game, a great experience. Libgdx seems to have the edge on the 3d front, but if you're expecting to be able to easily create a KILLER 3d gaming experience, neither framework will do the heavy-lifting for you. Libgdx does not seem to be even as far long a 3D toolkit as say JMonkey, which also can't compete with commercial kits.
Let's be honest, if you're trying to make a commercial 3d game to compete with other commercial offerings, you're going to have to license a commercial 3D engine (and have a pretty competent team). Neither project is going to provide the tools you need to get beautiful images up and running quickly... compared to say Unity's engine.
http://www.youtube.com/watch?v=Fc9m0Z1GDg8
The PlayN guys seem to be much more cautious about attempting to offer good 3D APIs without compromising the 2D APIs and the experience of working with them. Here you can read their cautious discussion about the best way to even expose the OpenGL ES 2.0 layer.
http://goo.gl/5f3ls
Libgdx's approach seems to be more aggressive by comparison. Both have pros and cons. I have some 3D calculations in my game using Vecmath sitting on top of PlayN. It's code, you can mix and match where feasible.
Given that they are pretty similar frameworks in terms of purpose and execution, there's likely to be a fair bit of cross pollination. You can see here that large parts of the Maven support for Libgdx was copied from PlayN's config.
http://www.badlogicgames.com/wordpress/?p=2707
Moreover, libgdx only supports iOS because of the work that Michael (PlayN) did creating IVKM. Mario then had to add JNI support for his C++ features as well.
http://www.badlogicgames.com/wordpress/?p=2791
Both projects are aware of the other and are mutually learning from the way each is beating a path forward.
In terms of stability, that's best gauged by the successful projects that each has. Tupsu & AngrybirdsChrome on PlayN, Ingress & others on Libgdx.
PlayN is pure java in as much as it sits on top of the Android/html apis etc. Libgdx seems to have some C++ on some platforms. This very much depends on what you are doing, i.e. for the web no C++ modules can actually be compiled by GWT. Further, Java is of comparable speed to C++ (usually a little slower, sometimes faster) providing you can keep the GC at bay and aren't dogmatic about how you use the language.
Having said that, C++ may still be useful in certain use cases.
Someone else answered that that Libgdx can support huge sprite throughput on single-core phones implying this is because of C++. This is NOT the area where libgdx is using C++. See features.
http://libgdx.badlogicgames.com/features.html
Both frameworks are likely to perform similarly in terms of sprite thoughput. You can have fun on with PlayN's web performance test here. Click on the stats counter to increase number.
http://samskivert.com/playn/perf-test/
Both have things like menuing UIs that sit on top of the frameworks.
Ultimately I'm sticking with PlayN, because I see no real reasons to switch yet and that's what I started with. Your mileage may vary.
