Thanks for the write-up @roasbeef 
What do you mean by “self identifying encoding”? The encoding you’re describing in your “Flexibility Middle Ground” section?
My personal opinion is that privacy is very important and needs to be protected. We chose from the beginning of the project to use onion routing because this was important to us (“us” meaning developers of the network). I strongly favor privacy over speed (within reasonable latency bounds of course): the goal of the lightning network in my opinion is to provide properties that you won’t find in traditional payment rails, and privacy and censorship resistance are properties we absolutely don’t have in traditional payment rails. Sacrificing those to get performance gains for which we don’t have any concrete use-case today doesn’t make any sense to me.
As we’ve highlighted several times during spec meetings, privacy loves company: you can only achieve good enough privacy if that is the default behavior of the network. Most users don’t care about privacy (for them, or for other users of the network): but more importantly, most users don’t know that they care about privacy until something happens to them, because of decades of telling people that if they haven’t done anything wrong, they shouldn’t have anything to hide. But I don’t think this is fine, and I’m afraid of what a society without any privacy looks like - and don’t want to live in one. So I’d rather have privacy built-in by default, and address the need for high performance separately, for example using direct channels (but again, since we don’t have any use-case today that requires very low latency, we can’t really design the right knobs for it).
If lightning succeeds at providing an open access to electronic payments for individuals worldwide, that offers good privacy, censorship resistance, low fees and reasonable speed (even 1-2 seconds is IMO reasonable speed compared to credit card payments), I would count it as an amazing success. I personally think that’s where it provides the most real-world utility and I don’t think we need to do “more” than that, I’d rather be 100% focused on making this use-case work well. I’m not at all interested in just building a faster VISA network.
Obviously, this is a “philosophical” question of what the developers of the network want: it always has been in every choice we make (feature we work on, implementation details, configuration knobs, etc). We’re not impartial and I don’t think we should try to be? We must be open to discussion and listen to our users, but in the end we all make a personal choice of what we want to spend time working on. And it’s great that different contributors value different properties!
I’m sorry if it looks like we’re slowing down progress on the attributable failures PR because of those discussions, but I think they’re important (more important than just shipping a feature without which the network has been doing fine for years). I understand the frustration (I have pending spec PRs that have been waiting for much longer than attributable failures), but I think this is part of the trade-offs of working on an open, decentralized network?