Por que o Derby e MySQL o único RDMBS que você considera? Se você disser Derby , você deve verificar HSQLDB , H2 , SQLite também. Se você disser MySQL , você deve conferir o Postgres também (que tem muito mais recursos).

Isso é apenas para citar alguns RDBMS gratuitos. É claro que, como Charlie já disse, existem muitos outros e muitos motivos para ir de qualquer maneira. Confira esta página de comparação (IMO excelente) na Wikipedia, onde você encontrará benefícios e limitações de qualquer RDBMS:

http://en.wikipedia.org/wiki/Comparison_of_relational_database_management_systems

No que diz respeito ao seu requisito sobre o seu webapp ser "downloadable", é claro que você pode incorporar um RDBMS (qualquer um Derby, H2, HSQLDB) em seu webapp. Mas você também pode simplesmente tornar seu MySQL ou Postgres ou qualquer integração configurável e dar aos seus downloaders instruções sobre como configurar seu aplicativo da web por conta própria. Afinal, quando você usa um DataSource configurado em contêiner para seu webapp, essa configuração pode ser feita facilmente.

Agora, mesmo que você ache que pode ser mais fácil desenvolver seu webapp com um banco de dados incorporado, você deve sempre pensar um passo à frente. Perguntas como:

• Você será capaz de se conectar diretamente a esse banco de dados para corrigir inconsistências de dados facilmente? (Isso acontecerá com todos nós)
• Você conseguirá alterar o esquema facilmente?
• Você poderá fazer backup de seus dados facilmente?
• etc etc... há mais questões de manutenção também

Como seus comentários sugerem que seus dados estão aumentando ao longo do tempo e devem persistir, eu não escolheria uma versão incorporada, mas manteria os dados separados do aplicativo. Observe que isso não exclui o Derby do design do seu aplicativo. Significa apenas que você teria que executar o Derby como um servidor autônomo.