I can't even comprehend why you're doing it like that. Do you expect users to write the routes down on a piece of paper?
Even when I know the route, I still (always) check it on my phone the very moment I leave the house, because I expect to get up-to-date information. If I can go to two different bus stops, I don't want to get an average! I just expect you to tell me which bus is coming first — right now.
The only situation when I'm checking a route ahead of time is when I need to know when to leave the house. For this I use Google Maps' "Arrive by" option, so even when I don't take the route immediately, I still expect to see exact times.
You realise that there is some lag in the system, right?
A small lag in data collection and transmission, a small lag in publishing the data via the feed (this is stated as 30s) and TfL cache the data points for 30s. Then you have the ingestion and processing lag that Citymapper introduce before they get it to you and display it on your screen.
You can estimate a lag of greater than 1 minute, pushing 2 minutes if you were unlucky that another CityMapper user nearby potentially requested the same data just before you and you're now seeing TfL's cache.
If you have a bus frequency of 7 minutes we're actually talking a lag of around 28% of the worst case wait time for that bus.
This experience would vary so greatly in different parts of the city (density of CityMapper users), that it would corrode your trust of the info.
Until that lag can be almost eliminated I think they're doing the right thing by choosing values based on average frequency and average wait time. The consistency means that almost everyone is treated to a similar experience, and though it is not highly accurate it is highly consistent. People can, and do, trust a highly consistent experience.
And yes, I live in London and use CityMapper a lot, and I've also played with those TfL feeds and experienced the real world lag in the data for bus/train arrivals, and bike hire data. Those data streams, when you walk out onto the street... they are only an approximation of what you really see outside.
You can cache times as ETA, and even in the worst case when an unexpected change in the schedule needs 2 minutes to propagate, it's still an improvement for all wait times longer than 4 minutes (i.e. all wait times that matter).
I don't see any reason that this lag couldn't be predicted in advance (similarly how NTP is able to synchronize computers' clocks even though there is latency on the network). Or use the last known "most accurate bus arrival time".
Even when I know the route, I still (always) check it on my phone the very moment I leave the house, because I expect to get up-to-date information. If I can go to two different bus stops, I don't want to get an average! I just expect you to tell me which bus is coming first — right now.
The only situation when I'm checking a route ahead of time is when I need to know when to leave the house. For this I use Google Maps' "Arrive by" option, so even when I don't take the route immediately, I still expect to see exact times.