On 1. I agree. Tracking needs to be accurate enough for the business case and the tracking experience can be smoothened. We follow these same principles. What value you attach to this depends on your value/effort expended in making it happen. We have found this to be a non-trivial problem.
On 2. Yes traffic inputs are important for ETA and we currently get that data from Google as well. However, it is not sufficient for many use cases that our current users have. Few examples: Google does not differentiate based on vehicle type (bike, car, van, truck) - we do. Google does not compute stop time at an address viz. time it takes to check out of a location after dispatch and check in to a location after arrival - we do. Google's APIs are point-in-time and you need to figure out the frequency at which you call the APIs in order to re-calculate ETAs. That gets complex due to the number of conditions that might trigger a recalculation.
On 3. Appreciate the point of view. Our best users are the ones who have done that and prefer to use us instead because they find it a complex problem that they do not have bandwidth or expertise in. Google APIs are not free and not cheap either. Besides the model is per API call and not per trip. Those who are paying those bills as well as paying for all the dev cost to make it work are seeing the value.
On 4. Constantly looking for ways to make our primitives more malleable for all use cases. Have been surprised with the number of use cases that users want to use HyperTrack for, and have consistently made the APIs more flexible. E.g. making each entity optional, making it easy to add/modify each entity on the fly, etc. I would imagine that every basic unit to be tracked (we call it task) would require a destination (if not at the start, eventually), and would require a person at the end of it (if not at the start, eventually). Do you have a suggestion on what would make it more universal?
Big fans of Twilio and Stripe, and have been customers for many years. Would love for you take a closer look at our service and backend infrastructure. We are not a layer on top of Google as you are suggesting. Google is a mapping tool and not a tracking tool. It is a common myth that the two are interchangeable. Locations come from the smartphone, not maps. Maps help make sense of those locations in a peculiar way. Our solution is different from the mapping domain, with some overlaps. Twilio and Stripe both have variable cost per transaction associated with telecom fees and interchange fees respectively. Working directly with telecom gateways and bank gateways are always an option. The alternative of directly using Google (which our users currently do for lack of a better option) incurs a fairly meaningful variable cost as well. To make it worse, the cost is per API call and not per transaction that impacts our user's life.