Route aggregation or selection does not impact forwarding performance on a router.
In practice this is only a small part of final performance, so you need to do end-to-end measurements to get a proper idea of what people will experience. Both Facebook[1] and Apple[2] have done that, showing 10% faster page loads and 40% faster connection establishment respectively on v6. Even if that was solely down to routing policies, it's still a measurable difference.
[1] https://engineering.fb.com/2015/09/14/networking-traffic/ipv...
[2] https://www.sidn.nl/en/news-and-blogs/apple-connections-esta...
In some cases, yes, the routing table size will impact performance; for example if the FIB is too big to fit in TCAM:
Note that this particular incident was caused by deaggregation of routes announced by Verizon, and that had the routes been properly aggregated it could have been avoided (though normal routing table growth would have eventually caused the problem anyway).
Geoff’s article on TCAM exhaustion is almost 10 years old. No BGP router in the default free zone has had a 512k route limit in years. Modern routers typically scale to millions of routes.
The incident in question was the result of misconfiguration and/or ISPs trying to run old routers past their usable life.
The whole thing was completely avoidable and not related to IPv4 vs IPv6 forwarding performance.
As to the IPv6 latency article, it can best be summarized as IPv6 sometimes has lower latency than IPv4, except when it doesn’t.
In no shape, way or form does the article claim that IPv6 forwarding performance is better than IPv4 forwarding performance.
There’s some hand waving about NAT, but it also notes that increasing the number of NAT levels improved latency!
The simplest explanation is that the differences come down to different routing policies in IPv4 and IPv6. Thus it depends on where you stand as to what you see.
What I want to know is do all these studies take into consideration the “happy eyeballs” algorithm that prefers IPv6 over IPv4 in web browser requests, thus delaying the IPv4 request?