It depends a lot on what you're doing, and how much data you're processing. If we go by the premise that you're processing more data locally than you would in a web app (because you don't need to worry about the latency and you don't have a server to do the pre-processing and filtering of the data before it reaches the client), then actual VM performance is more significant. The last time I looked at any profiles of browsers on Gmail or FB, JIT'd code actually accounts for several of the most expensive functions (and you will notice if you disable the JIT). JS performance does matter—even if DOM performance dominates in the case of the common website (and note that Mozilla has actually been doing quite a lot of interesting work around teaching the JS VM more about the DOM, including rewriting parts in JS, which allows JIT optimisation to happen).

It's definitely true that it's easier to write non-performant code using HTML/CSS (and <canvas> and WebGL don't really help here—because it's hard to ensure data gets correctly passed to accessibility layers), but I think that the majority of mobile apps are simple enough for it to not be a concern.

This is not to say that the browsers of today are optimally architected, of course. (In fact, I think they're quite suboptimally architected for 2015 hardware. The "it's too easy to fall off the fast paths" problem of HTML/CSS is a symptom of legacy browser architecture, not a problem with the layout/styling model.)