Yes, that's pretty much true. A big benefit (side effect) is that the DDL generation can lead to easier testing (especially when linked to automatic loading of seed data). For example, the test suite for Ebean at the moment is based on DB specific scripts which is not great.  DDL generation would mean the test suite for Ebean (and any application using Ebean) could be automated for numerous DB's. For testing purposes this could be a big win and this is the biggest motivation for me to support DDL generation.

Neither have I actually. I personally have always favoured spending some time designing a DB with a DB design tool (which was built for the purpose) and personally would perfer to use such a DB centric design tool to generate the DDL rather than beans with annotations (which are not going to include views, triggers, stored procedures, tablespaces, extra indexes etc, common data types/lengths etc).

I was expecting a JPA/ERD orientated design tool to exist by now which would be "the source" for generating both the DDL and annotated java entity beans. I have not seen such a tool yet but perhaps one exists?  If it did then I suspect it would have a number of benefits over DDL generation from annotated beans.

However, I believe there are Agile orientated developers expecting/wanting DDL generation and especially want it for quick development and automated testing purposes...  as well as a starting point for production quality DDL. The generated DDL could be sufficient for some DB's (smaller, no tablespaces, only used for automated testing etc) .

My slightly different spin on this would be "Don't fight the Database". The harder you fight the natural characteristics of the Relational Database design you are working with... the more pain you are going to have. Generally you are going to have to live with the DB design longer than the ORM/application. If the ORM generates a ORM specific DB design that could be a problem if later you want to swap out the application with another technology.

more DB centric instead of Object centric like Hibernate.  Especially
in the Query language.  No Restrictions and Projections and Criteria.
Good ol reliable Queries.

Well I agree in that I think Ebean is more DB centric and I think it will continue to be more DB centric.

Another way to look at this DB meta data issue is... Ebean currently hides the DB meta data it finds. Instead some of that meta data should possibly be on the entity beans (specifically the @NotNull and @Length annotations) with the benefit of supporting bean validation frameworks. Once you do this the value of the "hidden" DB meta data Ebean uses is reduced (to mostly automatic foreign key determination).

It is a bit more tricky with MapBean's which rely on the DB meta data. I'm not sure if they can be used without the DB meta data being available.