It might not be possible for everyone, but it sure made development much easier and each application was well received by the user base.
Typically when developing a Java web application you would use a web framework, either using J2EE (JSP) and usually an additional framework such as Struts/Tiles, or perhaps avoiding most of J2EE by using Spring, either by itself or with another web framework, or even using a servlet-based framework like Tapestry or Wicket. However you do it, the framework supplies the environment, generates HTML, processes form data, and all the other usual web workings. In your code you interact with the framework and also interact with some kind of database framework, such as plain JDBC, EJB, Hibernate or iBatis.
In a naked web application, the web framework and its (usually heavy) configuration is replaced by a much leaner architecture.
You could argue that I am simply replacing one web framework with a lighter one. I wouldn't complain, that's the whole point.
The three applications I worked on were an employee directory, a field office and staff information application (a sort of super directory with a lot of query options); and for a different employer, a digital printing press room management console.
The press application called an existing API and a bit of JDBC for data, and also interacted via a REST interface to other systems. This application was used to manage the companies digital presses, displaying all related print jobs in a large grid (updated in real time as orders came in), with various optional details and controls (deleting, pausing, restarting, etc), and allowed the operators to drag and drop jobs to the targeted press.
Development in all three cases was rapid and the details and functionality were constantly in flux. Spending a lot of time configuring a traditional web application, especially one with lots of XML to edit, would have been doable but far less productive. In two weeks I wrote 3 complete versions of the press application. It made testing new interfaces much easier, since I could easily build a functional prototype.
Now if I had to build an huge application with a large team, this approach might not be so easy. Of course readers might point out that I could have used Ruby On Rails but that wasn't an option for either employer. In any case this technique allowed my to get some of the benefits of the ROR approach without having to give up the Java environment.