I really like Wes Sayeed's answer. Multiple DHCP servers could be one reason why the request is useful.
Here's another reason: trying to re-use the same address as before.
The request is a request for permission to use the address. The Discover, Offer, Request, Acknowledgement is sometimes called DORA.
#
1: DISCOVER : Client asks the network (via broadcast message) for a DHCP server
#
2: OFFER : DHCP server responds, and provides a potential address
#
3: REQUEST: The end user machine/device sends a request to the server, requesting that the DHCP server allocates/reserves/uses up the requested address for that device
#
4: ACKnowledge : If the response is an ACKnowledge, not a NACK (negative acknowledgement), then the request is considered to be granted.
Here's the tricky part: The request doesn't need to match the offer.
For example: If a laptop went off-network for a while, and then tries to connect (to the same network or a different one), the laptop might want to use the same address if possible. Here is a sample made-up conversation:
#
1: DISCOVER: 0.0.0.0 asks 255.255.255.255 : "Can I have an address offered and know who you are?" The Layer 2 address sends from the device's MAC-48 address to FF-FF-FF-FF-FF-FF (broadcast).
#
2: OFFER: 192.168.0.10 says: "I'm a DHCP server. How about using 192.168.0.235?" This is sent back to IP address 0.0.0.0, and sent to the DHCP client's MAC-48 address.
#
3: REQUEST: 0.0.0.0 says to 192.168.0.10: "May I have 192.168.0.117?"
(For example, the laptop used 192.168.0.117 before.)
#
4: NACK: 192.168.0.10 responds: "No." (Maybe another system is using that now.)
#
5: Laptop gives up on being able to continue to use the address it wanted to.
#
6: (Perhaps after another DISCOVER and OFFER?) The DHCP client makes another REQUEST. So, using numbers already shown in this example, 0.0.0.0 says to 192.168.0.10: "How about letting me have 192.168.0.235?"
#
6: ACK: DHCP server says, "Okay. 192.168.0.235 is reserved for you, for the next 8 hours. Be sure to request a renewal before that time if you want to keep having that address reserved. Otherwise, I might give out that address to someone else."
So that demonstrates another benefit we have, thanks to the REQUEST step.
Now, since REQUEST is part of the design, the step really is a required part of the electronic conversation.
The DISCOVER and OFFER and basically conversations about planning. The REQUEST is the actual attempt to get a commitment. Nothing is actually committed until the ACK is made. A DHCP server could legitimately OFFER the same address to multiple machines, as long as it only ACKnowledges assignment of the address to just one machine. (I'm not saying that there'd be a good reason for a DHCP server to do that. I'm just saying the protocol/standard would allow for that without causing IP address conflicts.) The client is not allowed to use the address until it gets the ACKnowledgement, which only comes after the REQUEST. A DHCP server would not bother sending an ACKnowledgement before a REQUEST, because the typical DHCP client would not be ready for the ACKnowledgement until after it sends the REQUEST, so the typical DHCP client would ignore and miss the unexpected ACKnowledgement.