I would guess that GPS experiences like the article mentions are either driver app errors or scaling problems. That is, it sounds like the server is calculating the ETA of the driver based on a stale location. The location would be stale either because the driver app is not updating it correctly or because even when it is updating location correctly, the server is (sometimes) using an older location, probably due to an eventually consistent data store.

When I worked for Flywheel (Uber competitor, same general needs of "figure out the closest driver and provide an ETA"), we'd occasionally see drivers whose phones seemed to get "stuck" in a location, essentially because the location service crashed in the O/S and would stop updating the app (though this was on Android phones and not iOS, and I'd be slightly surprised to see it happen in iOS).

But I think that the scaling issue is the most likely. Location updates come fast and furious, and must be queried quickly. I wouldn't be at all surprised if Uber is using some kind of big scalable highly available database that could in the event of fairly routine network partitions report stale driver locations some of the time, and/or a cache in front of their underlying store that sometimes fails to get invalidated. That seems like it's consistent with the experience of the driver that the problem tends to happen on particular nights (when they're having some kind of underlying problem with, say, communication between components of their data store cluster), and why you might see it getting worse over time (as they scale).