Because RFC 826 doesn't specify what address to use, but indeed explicitly allow any address:
(ar$tha) Hardware address of target of this
packet (if known).
[...]
It does not set ar$tha to anything in particular, because it is this
value that it is trying to determine. It could set ar$tha to the
broadcast address for the hardware (all ones in the case of the 10Mbit
Ethernet) if that makes it convenient for some aspect of the
implementation.
So each implementation is free to use the broadcast address or not.
RFC826 is updated by RFC 5227, but it doesn't change this:
This document does not modify any of the protocol rules in RFC 826.
It does not modify the packet format, or the meaning of any of the
fields. The existing rules for "Packet Generation" and "Packet
Reception" still apply exactly as specified in RFC 826.
Nor does RFC5494, the other RFC that update RFC826
Regarding the request that already include the MAC addresses see RFC5227 section 2.3:
2.3. Announcing an Address
Having probed to determine that a desired address may be used
safely, a host implementing this specification MUST then announce
that it is commencing to use this address by broadcasting
ANNOUNCE_NUM ARP Announcements, spaced ANNOUNCE_INTERVAL seconds
apart. An ARP Announcement is identical to the ARP Probe described
above, except that now the sender and target IP addresses are both
set to the host's newly selected IPv4 address. The purpose of
these ARP Announcements is to make sure that other hosts on the
link do not have stale ARP cache entries left over from some other
host that may previously have been using the same address. The
host may begin legitimately using the IP address immediately after
sending the first of the two ARP Announcements; the sending of the
second ARP Announcement may be completed asynchronously, concurrent
with other networking operations the host may wish to perform.