Yes, this is exactly the issue why they're not already in there. The MAC needs to be unique in the table, but we can likely "just" use the IP address as pseudo-MAC.
The issue is more with the statistics. Given many users have a non-deterministic DHCP server (handing out IP addresses sequentially in the order of appearance of the device), it is a commonly seen situation that a smartphone gets the IP address 192.168.0.2 which was associated to a laptop on the day before. And this just because the device was switched on before the laptop on this day. All the statistics that were counted for the laptop yesterday would now be added to the same "device" because of the same IP address. I don't think I like this...
Note that the Pi-hole's internal DHCP server is in fact deterministic, i.e., tries to assign the same dynamic IP address to the same devices every time. This is also the reason why the first device can receive a pretty high terminal address such as 192.168.0.216 because we computed this IP from the hash of the MAC address of the requesting device. This to make per-client filtering possible even with devices that may do not even support (or honor) static assignments. I, for instance, do not have a single static IP (only exception is the Pi-hole itself) in my network. Everything else is dynamic.
There is not only a lack in validation, the entire logic seems to need a restructuring. Already on my todo list. ETA sometime next week.