Having correctly annotated beans opens up new possibilities as there
are

*) using of dynamic form generation like MetaWidget or Apache MyFaces
Orchestra's Sandbox stuff DynaForm
*) using of more sophisticated validation stuff like you can see in
JSR303 - Bean Validation
*) easer to read application as you can see in the code what kind of
database constraints are set up (e.g. NotNull, Length, etc).
*) and ok, finally allows DDL generation

For the more database centric approach of Ebean, I don't think we need
to fetch the db metadata. It slows down the first startup of Ebean and
will never be consistent after that if you change the db (it is cached
locally. I think it fetches new tables, but not table-column changes.
Correct me if I am wrong)
If you reflect those kind of things in your entity-bean, not only
Ebean can get rid of some complex code, but also the startup delay is
gone and your application will always behave how the developer wanted
it to do.

Regarding the qurey, I think, at least 95% of our queries are built
using the Criteria stuff. I fallback to hand written queries only if
there is absolutely no way around.

Finally, in the past, in our company we started a completely new
project where we just designed the entity-beans with all the
constraints and relations and let Hibernate create the database. First
for HSQLDB and close to production for Oracle then. It was a great
time-saver during prototyping.
Sure, in the end we handed those scripts over to our database
administrator to polish them. But he was quite happy about not having
to write all those basic stuff again.
And if I would start a new project with Ebean I would really miss this
feature.

This has nothing to do with OO purist. I am far from being one.

Having a good working entity-bean generator (from existing db schemas)
will then get the additional work from the developer.

Ciao,
Mario