we're not talking about protocol destroying bugs, were talking about things firmly in the realm of trade offs between marginal security gains and usability with security folks tending to be far too focused on marginal security gains while loosing sight of the big picture of less then perfect security that people use is better then perfect security that nobody uses.
I.E. ChaCha is better then AES because it is more resistant to side channel attacks among other things, but if you are creating a TLS server and can only choose one algo, you probably want to choose AES because more browsers support it compared to ChaCha and the marginal gains from ChaCha probably don't justify excluding those users that don't support it.
> If there is no central directory of identifiers to public keys, there's no way for a spammer to send spam
If there is no central directory of identifiers to public keys, there's no way my mom will use it to send me anything
She'd never use an app where you two bump phones with NFC?
That's because when it comes to security often theoretical vulnerabilities end up being protocol-destroying vulnerabilities in practice. Security folks are notorious for saying, 'that won't work,' being ignored — and then everyone being surprised when indeed it doesn't work.
> phone numbers allow for signal to be a drop in replacement for other messaging apps with minimal to no registration required
The issue is not allowing phone numbers as identifiers: the issue is in not allowing other identifiers. There's already a URN scheme for telephone numbers, and there are URN schemes for many other identifiers, to include email addresses, and there are even ways to add additional schemes. If Signal used URNs rather than telephone numbers, then users could continue to use telephone numbers but advanced users could use other identifiers, as they wish.
> lack of federation means ows can control spam better unlike in a federated environment where lazy/malicious operators can cause lots of problems
A spammer cannot spam someone whose public key he does not know. If there is no central directory of identifiers to public keys, there's no way for a spammer to send spam. It is possible for someone who knows one's public key to spam one, but since the sender's public key is tied to a public identifier, one knows who sent the spam.
Does Signal perform any anti-spam activity anyway?