Note that there's also fewer routes because each organization is getting a single IPv6 /32, which is enough (2^96 addresses) to cover their entire network regardless of who they are, as opposed to some organizations that have several IPv4 allocations that can't be combined/simplified. Therefore, less fragmentation of routes => simpler table. Thus, the IPv6 table will start reaching the density of the current IPv4 table when alot of new organizations that never had an IPv4 allocation start joining in the fun/mess.
Older equipment may have a problem eventually as the IPv6 information necessary to be stored will be about 3x the size of IPv4 information, due to the 4x size of the IP address fields. There's alot of old-equipment out there - because some people are of the opinion: "It works so why upgrade it?" They don't recognize the change coming. For example, Cogent, one of the top 10 tier 1 carriers, has an IPv6 allocation since 2003 but has yet to deploy IPv6 in their network. Many domain registrars still don't accept IPv6 glue for .com domains (e.g. register.com). In contrast, the registrar I use will store IPv6 glue even for domains in TLD's that don't yet accept IPv6 glue - for when they finally do.
When it comes to ISPs that subdivide and farm out smaller ranges (like HE), they still publish a single /32 to the world, even if internally, they split up smaller CIDR routes to individual peering points (e.g. tunnel servers, etc). So, what external BGP servers see is only the /32, thus keeping the routing table simpler than if every provider published each /64 that was routable because a client was assigned.
Why would a provider need to assign multiple /64's to any client? Technically, IPv6 stateless autoconfiguration need not occur at a /64 boundary. Despite the RFCs on the topic, any smaller CIDR boundary (higher-valued number) should be possible.
For example, my co-location provider, which HE is its only IPv6 transit peer, has a /32. I'm assigned officially a /64 (which might be a /48 as my 4th quad is all zeros), and the rest is apparently unassigned for now (as I'm the only IPv6 customer currently - so there are (2^32)-2 /64's available - they reserved the all-zero entry for themselves; currently unused). However, the BGP table will show only the /32. Only when packets for unassigned sub-routes hit their network will anyone find out whether a sub-route smaller than /32 is actually routable. Within my /64, only about 27 individual addresses will respond to the outside even though I have (2^64)-3 available (3 excluded are: all zeros*, all ones*, and the gateway address on my ethernet assigned to the facility's router).
* - I am aware that under IPv6, a node that doesn't know its own address uses "::" instead of all zeros within its prefix-masked-network, and that there is technically no "broadcast" (all ones) defined for IPv6, but this holdover in design from IPv4 is still present in some IPv6-capable routers.
Some people will still have to upgrade.
Also remember that due to "6to4", anyone who has an IPv4 address also has a /48 in the 2002::/16 "network." 2^80 IPv6 addresses isn't enough (by itself, let alone in combination with any native IPv6 allocation)?