I was trying to add a command="blah" limit on a key in .ssh/authorized_keys for the first time in many years; and a few problems struck me: 1) When I screwed up there was no log to say that it hit a badly formatted line in authorized_keys 2) A simple error - e.g. putting a line break after the command="..." part and before the key resulted in a key with no restriction. So I suggest if you find a command="....." or other option section that should be with a key and there is no key, then it should be logged that you hit it and you should stop reading the authorized_keys file because something is wrong. Ideally you should carry on reading the authorized_keys to check its validity, even once you hit a valid entry, that way you can spot other screwups - e.g. in my case I first misread the man page to think I was supposed to put the command="..." on the following line. OK, so you're not going to be able to catch all screwups; but it should be pretty paranoid.
It's a bit of a balance between providing safety and not locking people out of their hosts - an accidental ":wq" somewhere or a truncated key line shouldn't IMO be treated as fatal. OTOH, there should be some feedback in sshd logs about failures here.
I agree it's a trade off, but I think I'd like to have the choice to have a machine set up to be paranoid and make it fail with a bad line; either to fail on any problem or something like requiring every line to explicitly state anything that's allowed. I also think there may be intermediates of paranoid and permissive - e.g. maybe if you see a command="..." with no key then you could ignore the next key. It would take some thinking about though. Dave