You're right. The stride_usecs calculation, tm_delta += ustride_usecs, and final result calculations can overflow and need a guard.
However, I don't see the issue with the INT64 -> UINT64 mapping. The current implementation results in integer overflows (errors instead after the recent patch) even for valid timestamps where the result of date_bin() is also another valid timestamp.
On the other hand, the INT64 -> UINT64 mapping solves this issue and allows the input of any valid source and origin timestamps as long as the stride chosen doesn't output invalid timestamps that cannot be represented by Timestamp(tz) type anyways. Since all INT64 values can be mapped 1-to-1 in UINT64, I don't see where the problem is.