A DHCP request from multiple hosts can be differentiated using Src Mac Address. So, why do need DHCP client ID to differentiate the DHCP request. I understand that they need some IP address because DHCP works on Application layer. So, that IP address can be 255.255.255.255 for the destination. For the DHCP client the src IP will be 0.0.0.0. However, the request can be differentiated easily with the mac address. Thus, they really don't need DHCP client ID?
DHCP defines a new 'client identifier' option that is used to pass an explicit client identifier to a DHCP server. This change eliminates the overloading of the 'chaddr' field in BOOTP messages, where 'chaddr' is used both as a hardware address for transmission of BOOTP reply messages and as a client identifier. The 'client identifier' is an opaque key, not to be interpreted by the server; for example, the 'client identifier' may contain a hardware address, identical to the contents of the 'chaddr' field, or it may contain another type of identifier, such as a DNS name. The 'client identifier' chosen by a DHCP client MUST be unique to that client within the subnet to which the client is attached. If the client uses a 'client identifier' in one message, it MUST use that same identifier in all subsequent messages, to ensure that all servers correctly identify the client.
It allows the client to specify something other than a MAC.
RFC 2132, section 9.14 defines the Client-Identifier option.
In my opinion, this is absolutely mandatory to support DHCP relaying. In DHCP relaying, the src IP and destination IP's are changed. Also, the source and destination mac address. So, on receiving the dhcp messages from the dhcp server, the relay interface can't keep a track of the mac address. In fact, it will just forward the packet to broadcast IP with no accurate destination mac -address. With the help of client ID, the DHCP client can understand whether the packet is meant for them or not.