Thank you for reaching out to the transit data/GTFS community. Always useful to have a dialog on such issues.
Adding timepoint information can be very helpful. But there is currently an issue with the timepoint definition in GTFS. It can mean two very different things to transit agencies and to users. There can be 1) "operational timepoints"; and 2) what we sometimes call "schedule adherence timepoints". They are very different from each other. An "operational timepoint" is where a driver is to not depart a particular stop until the scheduled departure time. This is the type of timepoint that Google refers to in their documentation on the timepoint column for the stop_times.txt file:
Scheduled stops where the vehicle strictly adheres to the specified arrival and departure times are timepoints. For example, if a transit vehicle arrives at a stop before the scheduled departure time, it will hold until the departure time.
If a stop is configured to be a timepoint then real-time information systems are to take this into account when generating downstream predictions. It also affects trip plans.
A "schedule adherence timepoints" on the other hand indicates which stops are to be used for schedule adherence reports. Currently SFMTA does have specific stops that are considered to be "schedule adherence timepoints". But such stops are not supposed to affect the real-time information generated.
My experience with SFMTA is that the drivers do not adhere to "operational timepoints" even though I have been told years ago that they are supposed to. This is actually a very good thing from a passenger's point of view. It means that the transit vehicles operate as quickly as possible and don't pause in a frustrating way in the middle of the route to "catch up with the schedule". If you have ridden Trimet buses you have probably experienced these kinds of slow downs. Transit is slow enough as it is. We don't want to slow it down anymore with timepoints.
But if timepoints are defined in the GTFS, typical clients will treat them as "operational timepoints" and real-time information would be less accurate since that is not the way SFMTA drivers have been behaving. Vehicles would arrive at subsequent stops before the predicted time and passengers would miss their bus, a very poor user experience!
At Swiftly we can configure an agency such that timepoints defined in the GTFS will not match the GTFS specification and instead be treated as "schedule adherence timepoints". Therefore we are fine with such a change. But other clients will certainly have trouble if stops are defined as "operational timepoints" in the GTFS yet the drivers do not actual behave accordingly.
Therefore I first recommend that the SFMTA clarify whether drivers actually wait at timepoints until the scheduled departure time. If they do not, then it would be best to define the stops in question in a non-GTFS standard way, such as "schedule_adherence_stop" or "otp_stop", instead of as a GTFS "timepoint".