I agree. In fact I’d like to take this opportunity to apologize publically for arguing in favour of that option at the time. I’ve learnt from it and I also believe we should refuse any similar requests in future.
As a (non-succinct 
) proof that I actually have learnt, most of the rest of this comment is a detailed explanation of what we were thinking and why we were wrong. This is critical to help us make better decisions, to come back to and remind ourselves and spot analogies between this and any similar future cases.
The gist of the argument concerning privacy was as follows: the intended behaviour of wallets for payments to a TEX address is to send from the wallet’s shielded funds to a fresh ephemeral t-address, and then to the TEX address in a separate transaction. If implemented correctly this leaks no information, and therefore causes no privacy loss, compared to sending directly to a t-address from shielded funds. (There are nuances about paying multiple TEX addresses but we needn’t go into them.)
The privacy implications were the main potential obstacle to doing something to (possibly) avoid delisting from Binance. Given a solution to those, there was a realistic chance of avoiding delisting —at least in the short term— by adding the new address type. This could be done without a consensus change, and in a reasonable timescale and with reasonable effort (we thought).
There are several problems with that overall argument that I should have given more weight.
Working on “compliance” [mis]features costs engineering bandwidth and time that we vitally need. We’re essentially in a race for adoption of Zcash versus a regulatory and political attack on financial privacy. This is not hindsight; we knew it at the time of this decision.
As it happens, we severely underestimated the engineering and time cost, but note that there is always the risk of such underestimation for any non-trivial feature. So the fact that we underestimated this one in particular is not the relevant mistake. The mistake was not properly factoring in the risk of underestimation.
ZIP 320 is not even done yet! It still requires more work to ensure that any money sent back by the recipient of a ZIP 320 payment will be recovered. It involves code, database schema, spec, and ecosystem additions (e.g. wallet support for the address format) that will need to be maintained. Although I don’t know of any inherent weaknesses, the associated complexity creates ongoing attack surface.
We have previously noted that work on ZIP 320 support ended up overlapping with work on transparent functionality that was needed anyway for zcashd deprecation. That is true, but should be discounted in assessing the wisdom of our decision about ZIP 320. We didn’t plan in advance for that overlap, and so that wasn’t part of the decision. It would only be valid to take it into account as a positive if it had been planned. Also, it is possible that the necessary transparent functionality could have been implemented more simply, or avoiding some bugs due to the complexity of bundling it with the ZIP 320 support, or with smaller maintenance costs.
Not only the actual engineering cost, but also the perception (inside and outside the Zcash community) of what we’re spending time on, matters.
The potential value of the feature in avoiding delisting was and still is contingent on decisions of a third party. Binance haven’t dropped Zcash but they still could.
As @joshs pointed out, they could also just start sending back every payment that is one hop from shielded (which would include every ZIP 320 payment), forcing their users to send from t-addresses without the protection of those addresses being unconnected to their other t-address usage. Ensuring that protection manually would at best require unreasonable and unrealistic effort from the user, and is impossible in some wallets.
This isn’t even fully under Binance’s control. It depends on what their outsourced “risk assessment” providers do. We can’t assume those aren’t adversarial or won’t come under further regulatory pressure.
Related to risks of third party decisions, a lesser issue is that I inappropriately counted advantages of one of the two possible design approaches —the option using UAs that was dropped in favour of TEX addresses— toward the benefit side of the decision. I should have discounted those advantages given that it wasn’t under our control whether that option would be taken.
We should be focusing on decentralized exchanges. Many critics of ZIP 320 said so at the time, and they were right. The mistake here was in thinking that we would have enough bandwidth to do both. But in fact this has distracted to some extent from work toward DEX support. This was also predictable without hindsight.
That was a wall of text and perhaps there is also a simpler argument. Suppose you are an adversary trying to expend the engineering resources of ECC and other Zcash ecosystem participants unproductively.
What better thing to make us work on? Something that:
- Focuses attention on centralized exchanges.
- Has the risk of expanding to other exchanges (even if we tell them not to, as we have in some cases).
- Has the risk of doing nothing useful at all except expend effort, depending on future decisions of a third party.
- Requires a heap of complex justification in order to convince people (perhaps) of nothing more that we’ve stood still on privacy.
- Increases the complexity and potential attack surface of the protocol at the wallet layer.
It’s part of my job to consider the overall cost/benefit of proposed features from ECC’s point of view, and I don’t think I did so with sufficient skepticism in this case. Features that aren’t directly focused on directly improving privacy or the usability and applicability of the shielded protocol, at this point in Zcash’s evolution, need to clear a higher bar.
Note: we could have done worse. This decision was carefully considered, and it was made in good faith. It seems to have avoided delisting from Binance for now, which is what we were trying to achieve. What I think we got wrong is to over-value that goal relative to the costs. In that sense it wasn’t the right decision, and not just in hindsight. I take responsibility for that (both as ECC’s engineering manager and because my arguments were persuasive), hence this apology.