In my opinion, the project division should be pretty fine grained, even for "only a webapp".
I would make separate projects for the data access layer interfaces and implementation, business layer interfaces and implementation, and the webapp itself. I would also make atleast one "commons" project for containing code relevant to more than one of the other projects. But this is just the beginning. I would not hesitate to extract a commons-util project for utility classes relevant regardless of the application that is being developed (String, Date, Reflection, etc). I would also make a project for useful utilities when doing testing (commons-test). And that's just the next step ... ;)
If I wrote generally useful code relevant to hibernate, I would put it in a hibernate-utils project. Useful Spring utilities would go in a spring-utils project etc. When doing this, many projects will only contain a single or a few packages, and the packages will commonly contain few classes.
My reasoning for doing this, is that it helps me think about the code I write. Is this REALLY business logic, or is it general String manipulation, Date manipulation, Hibernate specific logic etc? My layers become cleaner, and it becomes harder to get circular dependencies between packages and projects (we don't want those). In addition, it becomes much easier to reuse code in other projects. There will always be other projects...
I have also found that it is easier for new developers to get a hang of the structure, because the projects become smaller and more manageable; it's easier to start coding when you feel you don't have to under stand everything.
As a last advantage to the fine grained approach, build times reduce because you don't have to build everything every time.