The person generating the table didn't realize filling the out-of-bounds with two would make for a simpler PLA. And the person squishing the table into the PLA didn't realize the zeros were "don't care" and assumed they needed to be preserved.
It's also possible they simply stopped optimizing as soon as they felt the PLA was small enough for their needs. If they had already done the floorplanning, making the PLA even smaller wasn't going to make the chip any smaller, and their engineering time would be better spent elsewhere.
The other thing that's hard for me to believe is there wasn't an extensive and mostly automated QA process that would test absolutely every little feature of this CPU.
It's possible some other result, likely aligned to an easy binary multiple would still produce a square block of 2, and that allowing the far edges to float to some other value could yield a slightly more compact logic array. Back-filling the entire side to the clamped upper value doesn't cost that much more though, and is known to solve the issue. As pointed out elsewhere, that sort of solution would also be faster for engineering time, fit within the planned space budget, and best of all reduces conative load. It's obviously correct when looking at the bug.