People embrace the DOM because its there, but that isn't necessarily a good reason. If jQuery is the C to DOM's assembly (not a particularly apt analogy), why shouldn't we want to branch out to a higher level language? That's one of the reasons we built Cappuccino.
Cappuccino is built on top of the DOM, because its the only thing that makes sense right now in the browser world. But we do our best to make sure developers don't need to worry about the DOM. Of course, as Spolsky would tell us, all abstractions leak and ours is no exception. But, Objective-J is just JavaScript. All the DOM is still there for you to poke at if you must. And the point of Spolsky's article was not that abstractions are bad, just that you should learn what you're abstracting, then use it. Abstractions do save us time, even when they leak.
As far as Objective-J itself is concerned, there were clear motivations for building it. JavaScript lacks dynamic message sending. It lacks classical inheritance. It lacks an import mechanism. We looked at what we felt was missing, and what the best way to fix it was. Turns out, Objective-C was created with exactly these same goals. It was a natural fit for what we needed, right down to implementation level details.
It's important, then, to realize that Objective-J is not about being Objective-C in the browser. It's a better JavaScript. It's a strict superset, so if you just want to use JavaScript, go ahead. If you want to benefit from our hard work and new features, like dynamic code importing, then you can use Objective-J. It even has a REPL: http://tlrobinson.net/misc/console_bookmarklet.html (and a command line version, objj)
Objective-J is also far different in its implementation than Pyjamas or GWT. It's nothing but a preprocessor and a dynamic runtime. It is not a compiler. This means that, in general, the post processed code looks like a slightly uglier version of what you really wrote.
[object message]
objj_msgSend(object, "message");
"It's possible to write good JS code" implies that it's not easy or obvious, and "it just takes some self-constraint" implies that in fact you have to be damn good to understand what you're doing.
That's fine, but mere mortals need a programming language too. Fact is that most large projects are not made of up entirely A+ developers (nor should they have to be).
Luckily core JavaScript is also pretty flexible, which is what allows you to implement your own class system, package system and so on, on top of vanilla JavaScript. And this is basically what language abstractions like GWT, Cappuchino, Pajamas and so on does. They are basically a set op macros on top of JavaScript.
I just think they throw out the baby with the bathwater by implementing a different language on top of JavaScript rather than just extend and improve existing JavaScript in a backwardly compatible manner. This forces the language abstrations to create their own set of libraries, which will never be as good as the native JavaScript libraries. You get caught in a ghetto, and isolate yourself from the broader JS communkty.
My own approach is to embrace and extend JavaScript in a bachwardly compatible manner, such that you can still use the large amount of native JavaScript libraries. Ideally "language abstraction" should be orthogonal to library abstraction. I want a more powerful JavaScript, but I also want to keep using JQuery.
Macros.
I only assert that once your (well, my) code base grows beyond a certain size---for me, a few thousand lines, but probably an individual threshold---JS can start to become unwieldy. That "unwieldy-ness" is a problem that Java/GWT does solve. In these cases I prefer Java precisely because it is more constraining.
Now, some of the DOM manipulation stuff is just annoying, but that's what jQuery is for :-D
What do you like better about Java's object system than JS's? I prefer JS's because it isn't as constraining - it doesn't force you to use it the way its creators imagined. It's possible to write good JS code, it just takes some self-constraint.