If PlayCanvas is meant to provide a web-first platform for game development, why use ammo.js under the hood? Cannon.js looks like a great JavaScript option, isn’t an emscripten port, and seems to have a larger community around it than ammo.js.
When we first starting looking for a physics engine, Cannon was in the very early stages of development and wasn’t ready to be used in a production environment. It still seems to be maintained by a single programmer as a side project. This makes us cautious about building a dependency on it as a product.
By comparison Bullet (which is the library that ammo is built from) has been used in tens (hundreds?) of games and is very well battle-tested. On the downside, Ammo is emscripten code and therefore generates quite a large JS “binary”, complex scenes can have performance problems on mobile.
We’re always keeping an eye on the other physics engines. For example there is also oimo which looks promising. If someone wanted to do a benchmark comparison project (hint) that would be very interesting 
Ah, production-ready is always a fair reason. Though ammo.js is, I believe, also a single developer handling the packaging process. I don’t mean to nit-pick, and I don’t care all that much, of course. I’m simply curious. I’ve been doing some side work to stitch three.js and cannon.js together; I’ll post up a blog and repost it here if I run into any issues 
If you’re interested in some quality benchmarking of physics engines, 0fps has done some benchmarking of collision detection speeds of several 2d physics engines.
(btw, great Meteor app!)