This is just my opinion on how and why I would do it this way. I am not developing this, so the core-devs would have to make the final decision in this regards by my $.02 is:
It should be strict to ensure that the API layer never does actions it should not be doing. With Dgraph GraphQL, this is a little harder to see at first. But as I explained in my edit after thoughts above, the GraphQL implementation inside of Dgraph is just that, an API. It takes the GraphQL and rewrites it using rules into DQL. In an API layer, actions such as adjusting timestamps are not permitted. If it was, then any user would be able to adjust a timetamp willy-nilly. Think of it how it may be with other database and APIs. If a timestamp is automated by the databse, then the API uses that automation of the timestamps and does not allow writing to that through the API. And looking at the implementation I wrote above, if the _updatedAt field gets set in a rewriting process into the DQL mutation, then allowing a user to also set this _updatedAt predicate could result in writing two values and then the rewriting process becomes more complex with needing then to decide when not to add in the automated predicate if it is supplied by the user. But I think the issue goes deeper than this…
I believe a client->server synchronization should be different than a server->client synchronization. Hear me out. Right now there are no good implementation that I have found for offline GraphQL. The only things really out there is client side cache of GraphQL (ie: Apollo Client). To update the client cache with a source of truth, the client should first update the source of truth (server) and then with the response update the cache. Therefore a client->server sync is not really pushing the source of truth, but is setting pieces of truths and returns the source of truth for those pieces (that would contain the timestamps). For any server<->server syncs that needs to set these timestamps, that should be done using DQL live imports and rdf streams IMO.
It would be interesting to see any implementation of client->server syncs where the client is collecting mutations and then running those in batches at a later point to perform sync. This would add more complications because the client would then be responsible for ensuring that there were no conflicts of unique ids and also require some sort of blank node implementation in GraphQL. I don’t think the GraphQL spec is ready yet for client->server sync.
For the time being, if you have a timestamp field you want to let the database control, let it control it, if you have a timestamp field that you want to control, then do so with a regular DateTime field as I stated above. This would get a timestamp feature into production quickly which could then be iterated upon for feature enhancements later.