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.
Your third question was answered in this thread: https://networkengineering.stackexchange.com/a/28807
A client may refresh its ARP entries by using unicast polling of the already known peer. I know my home router does this a lot. Every 30 seconds or so, it sends a unicast ARP request to my computer.
User halfmetaljacket above was correct in his assumptions.
According to RFC1222 :
Unicast Poll -- Actively poll the remote host by periodically sending a point-to-point ARP Request to it, and delete the entry if no ARP Reply is received from N successive polls. Again, the timeout should be on the order of a minute, and typically N is 2.
That's a great find by user Eddie