The best way to answer "security questions" is below:
sort --random-sort --random-source=/dev/urandom /usr/dict/words | head -5 | tr $'\n' " " ; echo
Adjust the head -5 to adjust how many words are output. Then your answer to "what was the name of the first street you lived on" could be:
crunched shirt wins ambushed titter
You gain an answer that has no relation to the question, as well as an answer that is easy to recite over the phone to a person (should the need arise).
They may as well just have had you create 2 different passwords - the Q&A was never good security in theory as it deals with a bad actor needing only to know a select few pieces of PII to bypass a user's legitimate password in the worst cases.
The 'security questions' were never about 'security' (at least not directly). As you say, they simply created a "backdoor".
They were always about: "automated forgotten password recovery".
As in, the companies did not want to employ telephone workers to handle the inevitable "I forgot my password, can you let me back in" calls [1]. They were only ever meant to allow for "reset password" via 100% automated means". That's why the questions are often so much of a sort of "ok, anyone who knows X, or does a little research on X, can figure out that answer" type. They were just that way because that also (hopefully) meant the "I forgot my password" users would not also forget their "recovery question" answer.
[1] Or, much more likely, bean counters realized that the call center size (and expense) could be reduced by 87.4% if we (bigco X) implemented a way to automate handling all those "I forgot my password" callers.
Security changes take forever. Old school sys admin and IT security types don't really like to keep up with web changes. And users don't know any better. And grandma is probably less likely to mess up a security question than figure out what to do when she upgrades her phone and loses all her 2FA.
