If your #1 goal is to keep your 133t bragging rights, then there are no such things as unnecessary nor excessive complexities.

10.0.0.0/8 might seem like a lot of addresses, but certain large companies have enough fans and chillers and miscellaneous things that can fill that space, and it takes a lot of effort to reorganize their network to better allocate those addresses.

Do these large companies really have 16,777,216 fans and chillers? That would be enough for each of Wal-Mart's 10,586 stores to have 1500 IPs each.

Or do they just have legacy allocation mistakes?

Some of those might be regular servers or networking gear that are required to have IPv4 addresses for one reason or another. For example, they might need to interact with fans and chillers.

> legacy allocation mistakes

Requiring the same globally unique prefix for devices that share locations or functions would eat up allocations faster than the number devices would grow. But there are definitely good reasons for allocating addresses that way, just as there are probably good reasons why the number of ports on a switch isn't always a power of 2.

Other times they might not have been able to allocate it more compactly - are you really going to go make routes for a /25 and a /26 and a /27 when you need 200 IPs, just to save a single /27 over giving it the whole /24?

There can also be reasons to structure it more sparsely than required for UX, namely to give a more hierarchical structure - maybe by region and store, or similar.

tl;dr it's not necessarily a mistake that your allocations mean you use more space than strictly necessary