Yes, I know you're aware of them :) And maybe I'm splitting hair here--I agree with you that Signal isn't as robust wrt anonymity as, e.g. Tor.
Signal explicitly considers anonymity/a private social graph to be a design goal. Their documented considerations of things like sealed sender and use of Intel SGX's remote attestation clearly demonstrate this.
Yes, these measures are imperfect. Like you say, it's a centralized service and has weaker anonymization properties because of that. However, because of its design, to de-anonymize Signal users requires the server operator to do continual, non-trivial work as long as they want to de-anonymize users.
In other words, deanonymization attacks against Signal users works just like any other kind of attack: the question isn't whether it can be done, but whether the attacker has the resources to do it. Presumably you'd consider Tor to be an anonymity tool. Yet, even though they're distributed, deanonymization attacks against certain users can succeed, given enough resources. (I don't mean to imply that Signal is equally resistant as Tor!)
Note: big fan of the work you all are doing at Amutable! I'm following the news eagerly. Best of luck!
Sure, I guess it's more a question of degree.
I still think the original point I was replying to ("don't stand out") doesn't apply to systems with "soft" anonymity like Signal. Even more importantly, arguing that specific features like custom servers or non-Firebase notifications are problematic because they "stand out" is particularly silly -- those features are the exact kind that are already fingerprintable by virtue of Signal's inbox design. Even if the social graph is somewhat anonymised, Signal does not attempt to hide that you are using Signal. (You could argue custom servers leak some data about your social graph but I'm not sure it is much worse than the theoretical leaks we spoke about earlier. And it's kinda notable that when Moxie argued against federated servers as a concept, that wasn't among the arguments he made.)