Dazu gibt es die eindeutige Antwort: Kommt drauf an!

Entwickler produzieren Software

Ein Argument für die Wichtigkeit von Entwicklerdatenbanken ist, dass Entwickler ja damit Software produzieren. Sie verwenden die Datenbanken zur Entwicklung oder zum Test. Oft gibt es ganz bestimmte Testfälle, die über Jahre hinweg weiter entwickelt wurden und Basis für Software-Abnahmen sind. Ein Verlust dieser Datenbanken kann entsprechend hohe Aufwände nach sich ziehen. Nicht dokumentierte Testfälle können evtl. gar nicht wieder reproduziert werden, was sich in einer fehlerhaften Software-Auslieferung niederschlagen könnte.

Administratoren entwickeln

Administratoren entwickeln administrative Abläufe. Auch Adminstratoren brauchen ein Übungsfeld. Falls die Software-Entwicklung inhouse stattfindet, können die für den Betrieb der Produktion notwendigen Abläufe bereits hier entwickelt, getestet und geübt werden.

In einem mir bekannten Fall wurde beim Restore der Test-Umgebung bemerkt, dass die Backups fehlerhaft waren. Schön, wenn man es nicht erst auf der Produktion merkt, sondern bereits deutlich vorher. So konnte schlimmeres verhindert werden. Backups, die nie getestet wurden, sollten keinen Admin ruhig schlafen lassen.

Performance-Tuning

Falls die Entwicklerdatenbanken eine entsprechende Größe haben, können Schwierigkeiten in diesem Umfeld bereits frühzeitig entdeckt werden. Auch werden die Abläufe des Performance-Tunings nicht so oft durchgeführt, dass die erstmalige Anwendung auf der Produktion im besten Falle wirkungslos bleibt. Immer mal wieder auf einer gut gefüllten Entwicklerdatenbank etwas auszuprobieren hat schon seine Vorteile.

Verteilte Entwicklung

Falls es viele Entwickler gibt, die einzelne Komponenten ungestört von anderen Entwicklern zur Einsatzfähigkeit bringen wollen, machen Datenbanken Sinn, die den aktuellen Stand der Produktion wiederspiegeln und sich jederzeit aus einem vorhandenen Backup mit einem minimalen Aufwand auf Entwicklerinstanzen wiederherstellen lassen. Ein kleiner Bestand an Basisdaten sollte enthalten sein. Für spezielle Testfälle gibt es Skripte oder andere Anwendungen, die diese Testdaten erzeugen können.
Hier würde ich dann auch auf weitere Backups verzichten und beim Verlust einer solchen Datenbank, diese eben schnell wieder aufbauen.

Die Datenbankänderungen der Entwickler sollten in gut dokumentierten Skripten vorliegen und in der Software-Versionverwaltung historisiert sein. Nach Abschluss der Entwicklung werden diese Skripte in den Aufbau der Entwicklerinstanzen integriert, um auch andere Entwickler an der neuen Version teilhaben zu lassen.