The REQUEST is broadcast for the case where there are multiple DHCP servers on the network and the client has received multiple OFFER responses, from RFC 2131 Section 3.1:
The servers receive the DHCPREQUEST broadcast from the client.
Those servers not selected by the DHCPREQUEST message use the
message as notification that the client has declined that server's
offer. The server selected in the DHCPREQUEST message commits the
binding for the client to persistent storage and responds with a
DHCPACK message containing the configuration parameters for the
requesting client.
The ACK from the server may not always be a broadcast packet, but could be in the case you examined. Part of the DHCP protocol allows for enabling broadcast destination for DHCPOFFER, DHCPACK and DHCPNAK messages. This is necessary because some TCP/IP stacks can't receive unicast datagrams until the IP address have been fully claimed and assigned to the network interface. From RFC 2131 Section 4.1:
Normally, DHCP servers and BOOTP relay agents attempt to deliver
DHCPOFFER, DHCPACK and DHCPNAK messages directly to the client using
uicast delivery. The IP destination address (in the IP header) is
set to the DHCP 'yiaddr' address and the link-layer destination
address is set to the DHCP 'chaddr' address. Unfortunately, some
client implementations are unable to receive such unicast IP
datagrams until the implementation has been configured with a valid
IP address (leading to a deadlock in which the client's IP address
cannot be delivered until the client has been configured with an IP
address).
A client that cannot receive unicast IP datagrams until its protocol
software has been configured with an IP address SHOULD set the
BROADCAST bit in the 'flags' field to 1 in any DHCPDISCOVER or
DHCPREQUEST messages that client sends. The BROADCAST bit will
provide a hint to the DHCP server and BOOTP relay agent to broadcast
any messages to the client on the client's subnet.