There are likely good reasons for not having this feature, but I don’t think this is one of them. If you need to delete a node and doing so would break the schema, you have two options: (1) have the database handle cascade delete, or (2) have the application figure out all nodes that need to be deleted and delete them all. Not performing the delete isn’t an option and neither is leaving unneeded nodes with broken relationships untouched.
So if the deletes must take place and the operation is slow, I guess the only remaining question is whether the application can perform the operation faster than Dgraph. I don’t think this is the case since the app is likely doing all deletes in the same transaction, not spreading them our or otherwise performing them asynchronously.
In my specific application, I maintain my own version of the schema that I can query to discover relationships and where the deletes should cascade. Then I construct the related queries and run them whenever a node needs to be delete. It would be nice to not have to maintain all of this extra code just to keep my graph consistent.