Bug/Vulnerability or just bad implementation?
Maybe it's because the article is referencing two different analyses on the issue, but I'm trying to understand why they are calling this a "bug" or "vulnerability" in SPF.
"Too many lookups" is something that has been known about for ages (although most companies probably have no clue when it's happening). The results of the lookup is "Permanent error". I would venture to say you should have a policy to reject email on both fail and permerror SPF lookups, so it would never be delivered. Otherwise, how will someone know their SPF is borked if people treat it like "dunno". Unfortunately, the RFC just leaves the choice up to the receiving end. Barring a complete block, you should at LEAST have increased scrutiny on the email (i.e. don't allow the email to pass DMARC or BIMI in order to call attention to the issue). However, that doesn't seem to be the case for the ups.com email.
In the ups.com email, the headers show SPF passed because Microsoft's servers were authorized to send on their behalf according to the ups.com SPF (they have since changed their SPF). DKIM alignment failed, since it was signed by onmicrosoft.com, but SPF alignment succeeded, thus passing DMARC (a requirement for BIMI). This still isn't a "bug" in SPF; it's doing exactly what it intended: say these servers (e.g. Microsoft) are allowed to send email purported to be from ups.com. The more interesting part is why Microsoft decided to relay an email FROM a "ups.com" address when the SPF check failed (and no DKIM signature). This touches on the problem of SPF as a whole (it breaks relaying). I believe Google only allows relaying FROM domains that you can prove you have some control over.
Ultimately this sounds more like an implementation flaw, not an SPF bug. BIMI is intentionally supposed to be hard to spoof, which is why you need to have everything set up the "proper" way. Requiring DKIM alignment is better in the long run anyway, since that is really hard to spoof.