Why does a Wake-On-LAN packet contain 16 duplications of the target MAC address?

In my opinion, the value has to be exactly 16.

Magic Packet Technology (whitepaper, publication #20213) was developed between AMD and Hewlett Packard circa 1995. From page 2:

"Since an Ethernet controller already has built-in address matching circuitry..." they propose reusing it, adding a counter "to count up the 16 duplications of the IEEE address".

They reason that WOL should be trivial to add, while leaving the actual implementation wide open. This doesn't appear to be historically arbitrary ("Oh, 16 looks long enough"), because:

1. Build on what you have / what you know. By example, let's assume we like powers of 2 and therefore hex digits. Conveniently, a hex digit (4 bits) holds positive values from 0-15. Our processor checks all math and sets an overflow "flag" if we try to add 1 to an already "max" value (like 15). Because that's pretty common, we may even have a special instruction for overflow conditions, so in pseudocode:

   Initialize a single counter that holds values from 0-15.
   Set it to 0.
   Watch the network. When I see the signal:
   Loop:
     Do I see my address at the right spot?
     Yes: Add 1 to counter.
       Did I just overflow? (15+1 = 0?)
       Yes: Jump out of loop to "wake up" code.
   ...otherwise
   Loop again.
   

2. Chip signal lines. AMD's reference to "circuitry" leads to the deep end, so all you really need to know is that we can imagine a simple case where a "bit set to 1" corresponds to a "high" voltage somewhere in a chip, visible at a "pin".

Arduinos are a good example: set a memory bit to 1, and Arduino sets an output pin "high". This voltage change is often demoed by driving LEDs, but through the magic of transistors it can automatically activate, interrupt or "wake up" other circuits or chips.

Let's assume a more natural hex representation (two hex digits, like FF, often seen in IP, masks and MAC addresses) and tie "output pin 5" of our Arduino to "bit position 5" in our counter:

Memory      Value  Event
0000 0000   00     Nothing, so keep adding 1...
0000 1111   0F     Nothing, but add 1...
0001 0000   10     Arduino pin 5 high. New voltage interrupts other circuits.

Because the memory location is tied to that pin, it's elegant and all hardware: just keep adding 1, no need to interfere with driver or BIOS developer code. You're just a circuit maker anyway. You'll provide a pin that goes high, to be consumed by other chipmaker's silicon, which is what everyone's doing. In the real world it's a little more complicated (for example, the ENC28J60 spec lays it out in horrifying detail), but that's the gist.

After this, human obviousness seems more a side effect than the goal. For computers, 4 copies of your MAC should suffice, but now that counter won't overflow and it's no longer dead simple. So it seems more likely that the goal was to get it implemented by as many silicon, driver, and BIOS designers as possible, and 16 gives everyone a choice between "overflow" AND direct signaling, without re-architecting and retooling.

Playing devil's advocate for human detection, what about the next higher number with the same flexibility: 256? That doesn't work: The data segment alone produces a WOL packet that's larger than an Ethernet frame (at the time) could be.

So to me this means that 16 is the only value the WOL segment can be.

Yes. It's simple and the chance that someone sends this data accidentally is effectively zero.

You want simple because a very low-powered microcontroller in the NIC has to be able to permanently watch the raw ethernet network traffic and act if it sees this pattern and you don't want to turn on systems by accident because a stream of random network data is the command to turn the system on.