First, the pipeline for actually building the game - what's the workflow like, what's your build system like, how easy is it to integrate with existing tools... If you're going to compare yourself to the goddamn Unreal engine, you had better at least have an answer to the utterly AMAZING tools they provide for artists, programmers, and other developers. Real game developers don't give two flying f--ks about whether you have Tumblr integration if they have to write a bunch of JSON to build levels and integrate into your build pipeline (and it's probably being generous to assume that their tech is sophisticated enough to use JSON files).

Second, the experience for players - sure, you've got a deferred renderer and a network stack. How much latency does your network stack introduce on top of the actual round-trip latency between the player and the server? How efficiently is your network stack able to use bandwidth (and is your prediction good enough to let me send less traffic for state updates?) How much memory and video memory do your demos use compared to a somewhat equivalent native app - will my players need a machine that's twice as beefy just to run a game in the browser using your tech? What are the average framerates like on an average machine - the canned videos suggest the framerates are bad, but actual runtime performance isn't even mentioned. How do you handle deploying assets for a game with a large amount of assets - is the player going to have to download 250MB of game textures and sounds into his cache every time he plays because you haven't done anything to cache them locally?

Toy demos like the one in the demo footage (http://www.youtube.com/watch?v=gjLaNjkYnrI) are basically only useful for demonstrating that it is possible to run toy demos. In the real world, you need to actually prove that you can run real games on your technology by running real games. It's all the more insulting that this toy demo seems to have repurposed assets from one of id's games in order to promote a product that these guys are trying to sell to you - I hope they got id's permisssion...

How about instead of trying to compare yourself to Unreal, you start with a lower target: Unity. Can you provide performance comparable to Unity across various target platforms, along with something approaching their ease of development and distribution? If you can't even compete with something as cheap/affordable as Unity on those points, then what is your unique value add that makes you a look? If the answer is nothing, well then, good luck - hopefully you have enough VC funding to burn that maybe you can be competitive before you run out of money.

EDIT: Oh, that's sneaky. If you dig into some of their documentation, it turns out that they require a custom binary plugin to support some unknown subset of their feature list because 'browsers don't support them yet'. So this isn't even technically an HTML5 engine; it's more like a native engine with partial HTML5 fallback.