> That's like saying "There is no requirement that the user doesn't tell their password to other people - all that matters is that the user remembers it".
... yes? I wholeheartedly agree with that statement so I'm really not sure what your point is. I have shared passwords with family members in the past. It works when it works and it doesn't when it doesn't.
> The "additional constraint" is the entire point.
I believe I already refuted that. Every practical implementation will have weaknesses. Being vulnerable to a greater number of attack vectors does not disqualify the method. All that matters is that the method works as intended for the attack vectors of interest.
I can bypass the lock on my front door by breaking a window. That doesn't mean that the thing on my front door doesn't qualify as a physical lock. It just means that my security model is vulnerable to certain attack vectors. That might or might not be a problem.
> You can't get rid of it without seriously degrading your security.
Whether or not my security is degraded depends on the extent to which the attack vectors the "additional constraint" was defending against are relevant to me. Writing my password on a post-it note and sticking it to my monitor degrades my security if the attack vector is someone breaking and entering my home. However it does not degrade my security even slightly if the only attack vector I care about is a stranger on a different continent illicitly logging into the associated account.
In general your thinking on this topic seems overly rigid and dogmatic. Security practices exist only to serve real world usecases. The expected attack vectors matter. So does user inconvenience. Something that is less secure but more convenient can often be the "more correct" solution in the real world. This is no different than how businesses will often choose to implement processes with well known flaws coupled with a response plan or insurance policy. For example shipped software often has bugs that were already known prior to release.
> a TOTP secret stored in a password manager will be leaked at the same time as the password itself when the password manager is compromised
Agreed. I went out of my way earlier to acknowledge the vulnerability to additional threat models.
> when you're using a password manager a leak on the website side is not a real threat
Well sure, but how are you going to get the vast majority of your users to use a password manager? They can always choose not to and there's approximately nothing you can do to reliably detect that.
You could mandate switching to a key based solution but then you'll get lots of complaints and maybe even lose customers. Or you could augment passwords with something else. TOTP is reasonable. So are SMS or email codes. Despite not being as secure or foolproof as a hardware token those solutions are sufficient for many scenarios.