"DHCP address reservation" specifically means that the router will always offer the given address whenever the host asks for one using the DHCP auto-configuration protocol.
However, only DHCP offers were made static, but the router's IP→MAC neighbour cache (aka the ARP cache) is still filled in dynamically using ARP.
Meaning, if you bypass DHCP and manually configure another host to use the reserved address, it'll work. As soon as the "IP → old MAC" cache entry expires, the router sends a new ARP query, learns the new MAC address, adds "IP → new MAC" to the ARP cache, and packets go to the 'new' host.
"ARP binding" won't necessarily affect DHCP, but it does add a fixed IP→MAC entry to the router's neighbour cache.
If another host tries to use the same IP address, the router won't know that. It will trust the fixed IP→MAC binding, and will always send packets to the "bound" MAC address, even if the host is actually offline.
(Note, though: When two hosts within the same subnet communicate, they don't go through the router but send packets directly to each other. So they'll use their own neighbour caches, but will not be affected by the ARP binding done on the router. Only Internet traffic will be affected.)
So far, ARP binding primarily sounds like a security feature – it partially avoids "ARP spoofing" attacks, and works even if DHCP is turned off entirely.
At the same time, though, it can cause even greater confusion, if the router thinks IP address X was bound to MAC X, but the rest of the LAN has learned that it is in fact MAC Y...
It is also not terribly secure since Ethernet MAC addresses are trivial to change or spoof. To make it useful, all switches on the LAN would also need the "sticky MAC address" feature enabled.
I can see it being somewhat useful for Wake-on-LAN, though probably not much better than just broadcasting the magic wake packet.