I think each approach is more suited to different scenarios:
Scenarios in which Database-first or Model-First are recommended:
- Long lasting databases with stable schemas
- Changes to database and model are incremental
- You want to be able to see your model in one diagram and update from there
- You can divide your model to non-overlapping diagrams
Scenarios in which Code-first is recommended:
- Development of model is done by programmers that are not interested in database
- Model classes contain logic
- Model classes have bizarre (non-standard) structures
- Model is divided between many assemblies that are not all known at design time (extensions)
- Databases are short lived (e.g. run-time of application)
- Database can change often
If you want a long lasting database which is dynamic enough to contain ever-changing structure, then consider generic classes/tables that your model/schema reuses for varying/context-dependant purposes.
Update:
I now recommend using Code-First for additional cases:
- When you want to be able to write and quickly and easily run integration tests on LocalDB (instead of working with SSDT)
- If you rather see the model and the mappings in a single place instead of going over diagrams and mapping windows
- If you want it to be more visible if someone mapped properties correctly or not e.g. as ConcurrencyCheck
- Since you can easily disable schema generating in non-local environments, the character of the database is less relevant