I think the missing piece in what you are saying is that there's an unspoken question here: "Secure against what?"
Let's use your examples to explain:
> You can support login over HTTP, which is quite insecure. You can support login over TLS which is much more secure. You can support only more recent algorithms over TLS which is more secure still.
Secure against what? If it's password exposure you're worried about, then HTTP is definitely not secure unless some other security is used. But given the attacks I know of against older versions of TLS, I don't think it makes sense to say that older versions of TLS are less secure against password exposure than newer versions of TLS, because the vulnerabilities I know of in old versions don't leak passwords[1]. So HTTP: not secure, TLS: secure, for password exposure. It's a binary whether it's secure for password exposure.
If, however, it's unauthorized access we're worried about, the CRIME and BREACH attacks are usable against all versions of TLS for session hijacking, so we could say that neither HTTP nor TLS is secure against unauthorized access. Again, it's a binary whether you're secure for unauthorized access.
So yes, actually each of these options is secure in a binary sense, when you ask what it's secure against.
Security, as a whole, as I see it, is a big `&&` of all the smaller binary pieces of security that matter for a given product. In reality, for most products, you have to be secure against password exposure and unauthorized access. It doesn't matter if you're secure against one if you're insecure against the other--that's what I mean when I say you're only as secure as your weakest link. So when talking about your security as a whole, it really is a binary: either you're secure or you aren't.
[1] This is for the sake of argument--don't take my word that older versions of TLS are secure against password exposure, as I haven't investigated that claim fully.
You're trying really hard to fit this into your binary model. Security is all about managing risk. It's not absolute. TLS didn't change when the CRIME attack was revealed, but it suddenly became less secure because the risk profile changed. But before CRIME, TLS wasn't perfectly secure. There was always the risk that the protocol could have undiscovered flaws, that an attacker could guess the private keys, that a cert authority could issue a valid cert to an attacker, etc.
In a world of imperfect security, talk of binary security is meaningless.
Let's use your examples to explain:
> You can support login over HTTP, which is quite insecure. You can support login over TLS which is much more secure. You can support only more recent algorithms over TLS which is more secure still.
Secure against what? If it's password exposure you're worried about, then HTTP is definitely not secure unless some other security is used. But given the attacks I know of against older versions of TLS, I don't think it makes sense to say that older versions of TLS are less secure against password exposure than newer versions of TLS, because the vulnerabilities I know of in old versions don't leak passwords[1]. So HTTP: not secure, TLS: secure, for password exposure. It's a binary whether it's secure for password exposure.
If, however, it's unauthorized access we're worried about, the CRIME and BREACH attacks are usable against all versions of TLS for session hijacking, so we could say that neither HTTP nor TLS is secure against unauthorized access. Again, it's a binary whether you're secure for unauthorized access.
So yes, actually each of these options is secure in a binary sense, when you ask what it's secure against.
Security, as a whole, as I see it, is a big `&&` of all the smaller binary pieces of security that matter for a given product. In reality, for most products, you have to be secure against password exposure and unauthorized access. It doesn't matter if you're secure against one if you're insecure against the other--that's what I mean when I say you're only as secure as your weakest link. So when talking about your security as a whole, it really is a binary: either you're secure or you aren't.
[1] This is for the sake of argument--don't take my word that older versions of TLS are secure against password exposure, as I haven't investigated that claim fully.