The separation between the presentation layer and the java code is a really neat thing. In wicket, your pages are plain XHTML, so you will not find someone writing scriptlets with application logic in your pages. Separation of concerns is really important, especially for large teams. What wicket did with the separation between the markup and the java code is really useful, where you can make your page designers and page authors take care of the templating, while your java developers take care of the application logic. If this is done right, you can easily boost up productivity a lot.
So do you mean to say, it does not even require a trivial amount of application/business logic in the presentation layer ?
In wicket all your presentation layer code should be implemented in java without scriptlets. And wicket uses swing like component model instead of MVC. Those are most important differences from other java web frameworks.
Whether you mix business logic with presentation layer is entirely up to you. I don't think that a web framework can prevent it's users from doing that.
Notice how I did not have to write any fragile url handlers. I did not have to pass count around in the url. I did not have to typeconvert it from String to int and to String again because it never shows up in the url. Count could have also been a complex object not easily encodable in a URL, with Wicket it doesnt matter.
I have a desktop-like programming model that takes advantage of java's core feature: OOP which makes Wicket code scale well to large teams because you can have encapsulation of code (notice count var is private), you can create new Wicket components easily by simply extending (notice I create a new link by extending Link component), and you can create new components by composing other components (notice I create Counter page by adding my link to it).