I don't consider it to be an "either-or". I think the best approach is "both".

If I were to win the lottery tomorrow, I'd hire a couple of engineers to take an Android dist. and add something like Cygwin to it (so it uses the Android display model, and not X, but provides API and ABI compatibility with X based applications), and then port GTK+ and Qt to that. I'd add bin-utils, shells, some other programming/development stuff (Sun Java, Python, Perl, Tk, maybe Tcl and Ruby), and a vt100 compatible "droid-terminal". Then I'd port a few common things to it (firefox, thunderbird, mplayer, a few others), and add a "me" account to it. I'd also look into adding the debian style package management to it, for the non-Dalvik apps (and the Ubuntu graphical counterpart, whose name I forget.. starts with an S I think).

That's how I'd approach it ... but I have an anti-X bias that says "it's better to start with the non-X platform and work toward the middle, than to start with the X platform". If I was Nokia, I'd start at the other end of that bias (due to the investment in an X based platform). I'd leverage the work the one guy at Canonical did (porting Dalvik to Ubuntu), and get Dalvik working on Maemo.

Though, the other thing I'd probably do, is see about supporting/leveraging fat binaries (1 executable file with multiple executable segments, each for a different platform). If I could work it into the native tools, it would be the default, with an option to allow developers to narrow it down if they feel it's strictly necessary. That would add some degree of flexibility to the native code developers, as well.

In general, I don't think it's reasonable to make developers or users choose between the two approaches (whether you're talking about Dalvik specifically, or Java generically). Evolution will determine if bytecode apps will do well enough to thrive alongside native apps (and visa-versa). Let the developers gamble, and the users decide. IMO, the OS platform designers job is to enable those two groups, not pigeon hole them.