I'd point out that the performance of Box2D physics is significantly determined by the number of velocity and position iterations, which currently default to 8 velocity iterations and 3 position iterations. This is the tradeoff between CPU work and physics accuracy. Comparing it to another physics engine is difficult, because it could use a default equivalent to say 4 & 2 iterations, making it less accurate but less CPU intensive. You can probably turn down the iteration count until Box2D is faster than another engine, but then the accuracy of the physics simulation suffers, and it is probably difficult to compare the accuracy of two different physics engines.
Further the C2 physics engine has features that involve adding callbacks to the physics engine which probably have a small performance impact - disable collisions requires collision callbacks, and the physics engine is also able to fire normal 'On collision' events upon physics collisions (which wouldn't otherwise happen). If another physics engine does not support these features, it has an unfair performance advantage since it does not have to do the same work.
We have a benchmark (based around circle collision shapes, which I think makes the difference) which clearly shows asm.js physics is about 3x faster than box2dweb in that case. So even if in other cases asm.js is about the same, if sometimes it's that much faster, it's definitely worth having.
We aim by the next stable release to have asm.js physics as the default.