Yes, because it's in the roadmap. And Schnorr isn't really controversial (why should it be?)
I don't know this roadmap. For me the roadmap has always been "lift the damn limit and let adoption grow". That's why I have been so opposed to all this.
About Schnorr ... I don't really care so much ... but a few ideas why it could be controversial. There are devils in the details. Just a few uneducated guesses ...
How is it implemented? As a new, optional transaction signature mechanism - or as a replacement of ecdsa? If the first, it will diminish its effects, like with SegWit, and add complexity to wallets and all kind of software. If the second, you have a masive risk of destroying everything, and you'll need to beware every software is ready when it is activated. I guess you can have endless fights about which version is worse.
The signature algorithm is the very heart of Bitcoin. Replacing / changing it should be controversial as long as the old one is not broken. Imho changing it should be a no-go as long as you have no really good reasons for doing so. It requires massive trust in the developers. Does Schnorr have enough advantages?
Rolling out Schnorr will require a lot of work. How can wallets deal with it? Are they able to understand transactions with Schnorr signatures? Or do their dev need to rebuild the Schnorr code in the language they use? How will block explorers show transactions with merged inputs? Will we have two methods to create multisig? Will merchants using blockexplorer's APIs or light wallets need to rebuild their payment algorithm to detect transactions with Schnorr signatures?
And, finally: What is the benefit of Schnorr to outbalance all the work, that the ecosystem's developers need to do and could spent on things which actually help adoption? Does it outbalance a felt negative of allowing devs happily doing a heart-transplantation of Bitcoin without a direct need? And so on.
@molecular
Apart from that I have an honest question: what exactly do you mean by "no change to the protocol".
Sorry for not answering the interesting part about Avalanche. Maybe another time.
For me it was always "lift the limit and let adoption grow". I am against nearly all changes which do not help adoption. Earlier I thought it to be a good idea to add confidential transactions, as it would help adoption, but after thinking deeper about it I don't think this is good. I would be ok with adding some kind of UTXO-commitment, as it helps adoption with the "run your own node" prepper bitcoiners.
I'm in no way ok of doing CTOR-Avalanche-Schnorr-Merklix-and whatever Amaury wants to to. None of this helps adoption, it even trades adoption against some perceived technological advantages which have not even any kind of contact with the current level of adoption. Imho they make BCH a science project of a "benevolent" dictator, that does not compete with Bitcoin, but with IOTA. I said this weeks, maybe months before the fork ...
This is just my impression of "no change to the protocol" and "roadmap". I don't expect you or anybody here to share it (except maybe Norway, Lunar, Cypherdoc and a few others), and I fully accept that you prefer to change the protocol to make Bitcoin Cash technically the best Bitcoin. I guess it is about preferences and priorities ... But to answer you question: I see not much potential in which BCH can match with what I want, while SV wants to represent it, as least they say it and I see not much evidence of them lying about this.