Well, it’s only a complex migration task if the new field derives it’s value from other existing data and differs from node to node. If that is the case, the migration has to be done of course externally.
However, a lot of times it would be just new added primitive fields (String, Int, Float, Boolean, maybe lists of primitives) that don’t depend on existing data and it should be easy (and useful) to provide default values for them I think. We could save so much time (both downtime and development-time) when these default values would just be inserted on a schema upgrade.
As an alternative to migrating the db and inserting new fields with default data, the @default directive could also work when the type is being queried. If a field is null, the default value is returned instead. I think that this approach is even preferable because it takes less time to implement and doesn’t need to iterate over and change the db. This could be implemented similar to @cascade.