The idea in SQRL is that surely if we show the user what they're about to do (e.g. sign into mybank.example), they'll realise they're being phished (e.g. by "notmybank.example") and abort. But the whole _point_ of phishing is that humans don't work that way.
In one of Microsoft's early experiments with this stuff they asked users to put their own _real_ bank credentials into obviously bogus sites with a variety of warning conditions to try to understand what's effective. _Nothing_ was effective, ordinary users click past the warnings of imminent doom in order to complete the task. I've written here before about "Brick Wall UX" the practice of designing security systems where there is no way to press on into danger. The reason for Brick Wall UX is that it _works_ and that's what WebAuthn/ U2F deliver for phishing.
In other respects SQRL isn't much different than other 2FA options like TOTP, although it has more moving parts. But because it can't fix phishing, it's not worth another look, if you decide phishing isn't scary enough to warrant extra work, TOTP already exists. If TOTP isn't good enough because you're (not unreasonably) scared of phishing, buy some Security Keys and do WebAuthn.
The goal is to automate away the domain verification. Since the addon doesn't have to know any secrets, it should be installed in as many devices as possible and eventually be included in the browser itself.
Also note TOTP is not an equivalent alternative because it has terrible UX in migration/restoration/revocation scenarios.
The FIDO device is impressively dumb on purpose, makes it hard to attack. Given an input and a hardware user interaction it responds, cheap ones aren't storing anything or doing any conditional work, and the interaction means you can't do any sort of brute force attack - if you somehow RCE the browser and prompt the user "please press the button a million times" they're going to report that as a bug and close the browser.