I think what's generally missing in these discussions is that the whole project to bring extensions into Fenix was extremely user-driven - whatever people actually use in any significant volume on Fennec, Fenix supports. And the actual UX of installing extensions is just so much more streamlined and nicer in Fenix.
If you purely look at it from the "most value for most users" perspective, Fenix extensions are a great success. And, it's also a success in purely engineering terms - code that's not bringing a lot of value but yet creates an overall maintenance drag is omitted.
What may have been missing from it is the ideological bit - for a platform to be truly open - and to be a viable platform!, it can't have a restricted "whitelist". And I agree with this. But it's not clear that "mobile-browser-as-a-developer-platform" is a sustainable long-term pitch for an organization as small and as resource constrained as Mozilla.
So, there's a tension between these two perspectives. In purely "rational" terms, what's there is good, and there are a ton of other much more pressing issues to work on for the small teams - bugs, performance, missing functionality that can actually "move a needle", etc.
You can make an argument that in this case, the rational, data-driven engineers won. Which is the opposite of what HN seems to think of Mozilla! What's probably needed for full webextension support is a strong, perhaps not purely rational leader that will rally folks and actually push the teams to do the work that may be useless, or useful to a tiny percentage of the user base, in a belief that it'll produce a better future. Which may or may not pan out!
