1. Keys are generated from the master key in a deterministic fashion. This means in the worst case scenario, where your master is compromised, rolling your keys is an all-or-nothing activity. You could just be in for a fun evening of racing to change all your account creds before a bad guy can use them. The only advantage this deterministic scheme has over a traditional encrypted keyring is that master key backups can be squeezed in to a QR code. The big downside is, if you want two or more accounts on, say, Hacker News you'll need to generate two 'master' keys and maintain a keyring anyway. Ugh.
2. Your super-sensitive master key is stored on all your devices. Sure, it's encrypted... but that means you'll need to enter a secure (realistically a ~8 random alphanumeric character) password, and wait a few seconds for strong key derivation, to use it. On mobile this is just a sucky UX, and will likely encourage users to use weak passwords or app writers to provide weaker encryption options, if only for the derived (site-specific) keys.
3. It doesn't provide server authentication, so you still need to depend on something like TLS + traditional CAs to ensure you're actually receiving your QR code from, and sending your signed response to, the services you expect and not MyEvilSite.com.
4. It doesn't provide integrity between the user agent and the signing device. When using optical scanning there's no way for the app to know that I'm signing facebook.com but my browser window actually says failbook.com. Even if the user is diligent there's no way for the user or the app to know whether the QR code on their screen is actually tied to their session cookie for facebook.com, and not another perfectly valid facebook session cookie created by somebody else. There's a weak proposal from Gibson to include IP binding but the IP isn't user/app visible (and if it were, requiring the user to be aware of such things is just bad UX). And even if IP binding is effective it still leaves you open when the attacker can use your IP (NAT, ARP spoofing etc, XSRF will even bypass TLS). The class of attacks open because of this gap in the auth-chain is one of the most insidious on the web atm.
5. The server side implementation has a lot of moving parts. A typical webapp needs to generate a secure session cookie, optionally bind it to the users IP and generate a QR code, wait for a sig from the signing device (under some timeout as to not allow unused codes to clog up the database), map that sig back to the users session, do IP and signature checking, update the session state and then somehow refresh/redirect the original client (or have them do it manually which is a sucky UX).
Frankly SQRL 'the protocol' just isn't very novel, and Gibson has only scratched at accommodating some of the hard user facing problems. Much of the above can fixed, but not all.
If you like QR code mobile authentication (well actually bar codes), go with Clef. They're still vulnerable to much of the above, only encrypt your 2048 bit RSA master key on your phone using your 4 digit numeric PIN, and it's just vanilla OAuth behind the scenes, but they've at least nailed down usability and settled on a relatively secure compromise.