It's difficult for us to support DOM-less engine. We see DOM-less as a disadvantage, not an advantage, because we support so many features that happen in the browser layer such as WebGL, Web Audio API, WebSockets, etc. etc.
I wouldn't expect Construct 2 to run in Pender in it's entirety. I have some experience embedding existing projects in Pender, including work for Zynga (not public unfortunately) and Bonsai.js from uxebu.
Two easy ways are:
1. Construct2Shim.js: which would redirects canvas calls through a messaging api to Pender, not as optimized as a full renderer running in Pender, but tests still indicate a massive jump in framerate and rendering performance. Easy to implement, with no change to ConstructJS, just a shim to be loaded in the WebView
2. Construct2Pender.js: which would define a tiny rendering engine using the graphics calls Construct2 expects to exist in the WebView. Instead of calling a canvas in the main Construct2 runtime, we would call Pender through the bridge, using an abbreviated syntax which would update the rendering engine.
Note that Pender can include any functionality that the device supports, exposed under any api we want. The Pender roadmap includes support for Web Audio and WebGL!
To echo your points, the DOM is most certainly an advantage when it comes to layout and the breadth of api's available. However, it kills rendering speed even when hardware acceleration is implemented in the browser. Decoupling the rendering engine is not only good architecture, but it allows a paper thin layer between the js and the native graphics calls, really bridging the gap between js graphics and native graphics.
One of the use cases of Pender is to provide embedded canvases in a Cordova/PhoneGap project, using the Pender runtime as a rendering engine for fast canvas, and not as a replacement for all that HTML5 offers.