The short answer is because there are evil people in the world who want to trick you. (Or maybe they made a mistake ðŸ¤.) When an atproto DID wants to use a handle, the right mental model is to imagine both the DID and handle to be two distinct resources in the atproto ecosystem.
The handle is an abstract resource that represents a domain. In practice, a handle takes one of two forms: a DNS (TXT) record containing a DID the handle intends to represent, or an HTTPS response from https://my.handle.com/.well-known/atproto-did (also returning a DID the handle intends to represent). Either of these concrete forms prove that a handle intends to represent a particular DID.
The DID is a resource which takes the form of a document (think JSON object). If the DID is using the plc method, I believe the DID document is stored in the DID user's PDS. For the purposes of this explainer, you can think of the DID document as a handle the DID intends to use, plus other important values.
For a handle for a user to be valid, both of these must be true:
The handle needs to show intent of representing a particular DID
The DID needs to show intent of using a particular handle
Without verifying both, a rogue handle could claim to represent your DID, or a rogue DID could claim your handle.
An interesting observation is that neither of these pointers (the intent by the handle to represent the DID, and the intent by the DID to use a handle) have any weird cryptography shenanigans going on. There's no encryption or signing happening here*.
*Ok technically, the transport of https://my.handle.com/.well-known/atproto-did request (or the DID) to you is secured via HTTPS^ or something. But we're not talking about MITM at the network layer in this explainer; we're focusing on participants in the atproto ecosystem. (Is this also a network?)
^The DNS TXT record is not secured. You'll have to ask someone who knows more about DNS than I do if you're also wondering why DNS doesn't require signed records for clients to trust responses.