I suspect you're confusing it with someone else's work. Although I hadn't seen anything which was particularly similar, it wouldn't surprise me if such articles do exist elsewhere -- many people do have the same opinion of SPF, of course. Please could you provide a reference to the article with which you were confusing mine? I'd provided links to the only ones I knew about.
I'm not sure why you think the arguments are unsound and unsubstantiated. For the sake of conciseness I assumed the reader would have a reasonable understanding of how email works in theory and in the real world. So I didn't go into mind-numbing detail for the benefit of those who lack such knowledge; providing an 'email 101' course wasn't my intention. However, I don't see that I ask the reader to take any great leaps of faith without pointing at the reasoning.
If there's anything in particular which you don't understand, please don't hesitate to ask for clarification -- either in fora like this if you think it'll help with general education of the peanut gallery, or in private email if you prefer. You'll need to be far more specific about your queries though.
You say that "neither a whitelist nor a blacklist seems to solve all use cases". That's true; each performs an entirely different function and cannot sensibly be abused as if it were the other. That is my point, in fact. SPF offers a whitelist and not a blacklist, and using it as if it offers a blacklist is wrong. Yet that is the usage which is being advocated, and the usage which I'm warning against.
What most people need is a blacklist-style answer. You want to be able to know that you can reject a given mail. A whitelist is a more esoteric thing, which just allows you to bypass certain other checks for trusted incoming mail. Using SPF as a whitelist isn't what I was talking about, and isn't what most of its users are doing with it. See my response to elanthis on a similar topic -- as with many technologies, of course you can find something to do with the information in SPF records which isn't utterly broken. That was beside the point; I was speaking of the way it's advertised, as a way to reject mail.
Your comments about prevention of IP spoofing seem strange. Mail forgery isn't done by IP spoofing. A lot of ISPs do prevent subscribers from forging their source IP address, and certainly you don't get packets back which are destined for the IP address which you're spoofing. It's fairly much impossible to conduct a TCP session using a spoofed IP address from a trojan dialup or broadband machine.
Disallowing dialup clients from making outgoing connections to port 25 of anything but the ISP's mail server is a good idea, already practised in by FreeServe in the UK, for example. But it doesn't entirely block trojaned systems. Those domains offering SMTP AUTH to their users in order to use SPF/DomainKeys/SES/etc. will need to use MSA on port 587, and trojaned systems can use that route to deliver their unwanted mail.
You also seem entirely confused when you refer to "problems with forwarding services that don't themselves publish [SPF] records". Whether the forwarding site publishes an SPF record is entirely irrelevant. In the SPF world, every server which forwards mail would have to perform some arcane mangling of the reverse-path in transit; a process which even the inventor of SPF admits is unworkable. But if you'd actually read my article before commenting on it, you would have known most of that.