It's become used for person-to-person communications, as well as computer-to-person communications, and is probably one of the few standard, interoperable, near-ubiquitous means of reaching people, short of postal mail and carrier-provided services like SMS and voice calling.
While requiring people to know who they want to correspond with before the fact could be helpful, it also breaks a lot of popular use-cases for email - email is often written into contracts as a valid means of serving notice etc pursuant to the contract. Locking email down to only receive mail from approved senders would break a lot of things, but certainly help to prevent this kind of spam.
I wonder to what extent this could be reduced however by using unique per-use aliases - in a sense you can get a softer version of this whitelist by giving out per-sender inbox aliases, and therefore seeing which alias was used to send a message. Not quite sender authentication, but perhaps better than nothing. Doesn't prevent compromise of the underlying (human-to-human) email address, but would certainly help with a lot of phishing-type scenarios using breached customer records.
This wouldn't require any special action from other people. You would automatically be a bit more suspicious when looking into the "unknown people" inbox, and if you verify the author, you add their name into whitelist and automatically move all their e-mailt to the "known people" inbox.
You could also set it up this way for your less tech-savvy relatives, and ask them to call you immediately if they find something in the "unknown people" inbox.
The problem for most users is that they won't recognise people's email addresses as signal - it's just noise to them. They don't know how to parse a domain backwards from TLD/ccTLD to determine where it goes, and even if they did, homographs and other international characters can fool them fairly easily.
Maybe the solution is something like SSH with trust on first use? Where users get alerted to a new display name and are asked to approve it the first time they send an email. Then a bundle of sender email, DKIM/DMARC/SPF success is stored locally, and future emails need to match that, otherwise the user will be warned this might not be the right user.
It seems without cryptographic identities (vouched for through PKI, a la S/MIME) that this is a hard problem to solve when you take into account the human factors and how much the existing solutions rely on the user.