Yes this is certainly a valid approach to data management, depending on your data retention levels and data structure for particular tables.
I wouldn’t put this in place solely for the purpose of synching to other systems.
From the point of synching, this activity is considered an update, not a delete.
Where you do delete records, they won’t be detected by looking for changes since last synch date, or by looking for a field “have I been synched”, because the record is no longer there.
Doing a full search and comparing to what you have locally is one way to find what is deleted, it can work for small data sets.
For large amounts of data, it makes more sense to keep track of what is being deleted, just the identifiers need to be kept and a deletion time. Then it can be kept in synch in a similar way to updates, and purged when synched.
In practice though you’d need to cover the inter-table relationships …
Delete a student, then a class enrolment table which had that student gets updated also. Perhaps the way Bubble removes the student in the enrolment’s list is good enough, but does the enrolment record get its modified date updated too?