Why the list is unlikely to be traversed?

If I understand correctly, the list is embedded into struct page itself (one of its many packed fields). It means that if you want to do anything with the page you will need to load it into a cache line anyway, so there is (almost) no additional overhead.

A similar idea is often used in userspace (and also in the kernel, I guess) which is a "free list". You embed a list in the things you want to keep track of so that you can easily handle "allocate a thing" request by just returning a pointer to head (while you update the pointer using the embedded "next" pointer in the thing you just returned). This "embedded list" might be temporary - once you return the thing you can get rid of the list pointer, so you can easily handle same-sized memory chunks (at least sizeof(void*) long) without any overhead. And once you put the thing back on the list you reinstate the pointer and put it at the head.

The only issue is when you need, say, 10 pages at the same time. The CPU will need to traverse a linked-list and load each struct page one after another. For the array variant, the CPU will still need to load each struct page but it can do so in parallel. However, I believe the use case here is to just ask for one page at a time. Heck, you can even try to prefetch the next struct page if you want to (though that is CPU-dependent).