As defined in RFC4408, Sender Policy Framework only checks the envelope sender (aka MAIL FROM). The From: header is not being tested. As it is the value of the From: header which is usually displayed in email-clients, the attacker may use a random envelope sender which might even have a valid SPF-record for the used IP.
Recipients will only find out about a forged From: header if they check the Return-Path: header (which is set to the value of the envelope sender by the MTA) manually.
So, how do SPF-checks prevent spam or phishing?
SPF on its own does not entirely block spam, because as you point out, it uses the MAIL FROM domain to load SPF policies. Since an attacker can manipulate MAIL FROM to their advantage, they're free to use MAIL FROM from a domain they control and then spoof your domain in the From: header.
Where SPF becomes really effective is when coupled with DMARC.
DMARC will look at a message and see if it is authorized using SPF or DKIM (only one is needed). After one of those mechanisms passes, all the domains that passed the checks are compared with the From: domain. If any of those domains and the From: domain match, they're said to be in alignment and the message is considered authorized from DMARC perspective. If alignment fails however, the DMARC policy you publish over DNS, is applied.
You have the choice of asking that messages that fail DMARC be sent to a quarantine/spam folder system or even ask that these messages be rejected outright.
DMARC also lets you request that receivers send you aggregate reports so you can understand how your email is being processed around the planet.
Gmail, Yahoo, Hotmail and many other organizations already participate in DMARC.
DMARC.org has a list of resources to help you learn more about DMARC.
There's also Scott Kitterman's DMARC configuration assistant
DMARC is not a silver bullet; it won't block spam where the From: domain is not under your control. However blocking attackers from spoofing your domain is a high value option in terms of forcing attackers to use other strategies that are more open to intelligent filtering in your spam pipeline.
As with most security issues, this mechanism doesn't fully prevent the problem, but it makes it harder for bad guys to overcome.
In this case, the protection that's offered isn't what is displayed in an email client, but rather it helps the mail relay on the receiving side to decide whether to accept the mail (or possibly tag is as spam). This is before the mail ever gets to the end client. By checking the IP of the sending relay against the "allowed" IPs that are contained in the sending domain's SPF record, the relay can see if mail originated from an approved IP.
Naturally if you can spoof the source IP, or poison the destination relay's DNS query against the SPF record, you can beat the system. But that's harder.